All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.