From: Mike Snitzer <snitzer@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] lvcreate and lvremove --quiet option is not quiet
Date: Tue, 15 Feb 2011 12:04:45 -0500 [thread overview]
Message-ID: <20110215170445.GA20233@redhat.com> (raw)
In-Reply-To: <AANLkTi=AyuuNrea0n3Dy9Lzu0=pm59Etd0n_rvCpM4Hz@mail.gmail.com>
On Tue, Feb 15 2011 at 11:07am -0500,
Jeff <jlar310@gmail.com> wrote:
> On Tue, Feb 15, 2011 at 7:41 AM, Mike Snitzer <snitzer@redhat.com> wrote:
> > On Tue, Feb 15 2011 at �8:02am -0500,
> > Jeff <jlar310@gmail.com> wrote:
> >
> >> On Mon, Feb 14, 2011 at 12:14 PM, Alasdair G Kergon <agk@redhat.com> wrote:
> >> > The simple problem is that the code today does not distinguish between
> >> > essential output (to stdout) and incidental output (to stdout).
> >> >
> >> > If I run 'pvs' I expect a list of PVs.
> >> > If I run 'pvs --quiet' do I still expect to see that list?
> >> >
> >> > Today, there is no distinction: pvs output and the message you're wanting
> >> > to suppress are the same category of message.
> >>
> >> Yes, there should be a difference between "do-something" commands and
> >> "tell-me-something" commands. I hope there aren't too many cases where
> >> that's a gray area.
> >
> > Ignoring the fact that we have a --quiet option for a moment, why is
> > the additional output of the command(s) so problematic?
>
> In short, the --quiet option isn't quiet.
>
> In the case of lvcreate and lvremove it prints purely informational
> confirmation messages to stdout. I find this somewhat inconsistent
> with other linux commands that offer a --quiet option (rsync for
> example).
>
> It's not so much problematic as it is an issue of good design and
> documentation. It's easy enough for me to send stdout to /dev/null in
> my scripts, but that does run the risk of missing important
> information in the case of unexpected results. What if the program
> isn't so precise about sending error messages to stderr?
well lvm _should_ send all errors to stderr.
> As already stated, for commands such as lvcreate and lvremove where
> the user is requesting the lvm system to "do something" and not "tell
> me something" I think the --quiet option should actually make the
> program be quiet, which it does not in the current implementation.
Noted, definitely an lvm short-coming.
> I am not a hard-core c developer and it's not likely that I would be
> able to find the time to contribute trustworthy patches. If the
> lvm-powers-that-be wish to ignore me, I can live with that. I simply
> saw a potential improvement and chose to share my thoughts.
Not ignoring you at all. This should get cleaned up. I was just
pointing out that --quiet not actually being quiet isn't a showstopper
at the moment -- so such a janitorial audit can be deferred.
Thanks for the report,
Mike
prev parent reply other threads:[~2011-02-15 17:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-14 15:46 [linux-lvm] lvcreate and lvremove --quiet option is not quiet Jeff
2011-02-14 16:31 ` Ray Morris
2011-02-14 17:43 ` Jeff
2011-02-14 18:14 ` Alasdair G Kergon
2011-02-15 13:02 ` Jeff
2011-02-15 13:41 ` Mike Snitzer
2011-02-15 16:07 ` Jeff
2011-02-15 17:04 ` Mike Snitzer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110215170445.GA20233@redhat.com \
--to=snitzer@redhat.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).