On Thu, Oct 24, 2013 at 04:51:00PM +0200, David Sterba wrote:
> On Wed, Oct 23, 2013 at 10:08:16AM +0800, Anand Jain wrote:
> > On 10/22/13 10:33 PM, David Sterba wrote:
> > >On Tue, Oct 22, 2013 at 01:53:22PM +0800, Anand Jain wrote:
> > >>@@ -386,7 +395,7 @@ static int btrfs_scan_kernel(void *search)
> > >> static const char * const cmd_show_usage[] = {
> > >>- "btrfs filesystem show [options] [<path>|<uuid>]",
> > >>+ "btrfs filesystem show [options|<path>|<uuid>]",
> > >
> > >Options should stay separate from the path/uuid, you're extending the
> > >syntax to accept a device:
> > >
> > > "btrfs filesystem show [options] [<path>|<uuid>|<device>]",
> > >
> > >I'm fixing it locally, let me know if this doesn't match what you've
> > >intended.
> >
> > I am confused, on how the options should be represented,
> > but the internal design is as below.
>
> Hm right, it is a bit confusing, I think because of the syntax that
> allows either options or the path/uuid/device specifier, not both, which
> is not so common.
Typically, that ends up written as something like:
btrfs filesystem show [options]
btrfs filesystem show [<path>|<uuid>|<device>]
or just as
btrfs filesystem show [options] [<path>|<uuid>|<device>]
with a comment in the man page that the second parameter can't be
supplied with any of the options (if that's the case). Of the two, I
prefer the former, but with the acknowledgement that when the command
grows some options that can be used with the p/u/d, you'll end up
having to change the help text.
Hugo.
> I still prefer to keep them separate, because it's something that can be
> clarified in the help text or documentation.
>
> Besides, that we may want to add more options that affect
> path/uuid/device output, the argument description looks consistent with
> other commands and if some combination is not allowed, then an error
> message will say why. I really don't expect an average user to think too
> hard about it.
>
> david
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I believe that it's closely correlated with ---
the aeroswine coefficient.
Attachment:
signature.asc
Description: Digital signature
