On Mon, Jun 18, 2018 at 01:34:32PM +0200, David Sterba wrote: > On Thu, Jun 14, 2018 at 03:17:45PM +0800, Qu Wenruo wrote: > > I understand that btrfs-progs introduced restrict parameter/option order > > to distinguish global and sub-command parameter/option. > > > > However it's really annoying if one just want to append some new options > > to previous command: > > > > E.g. > > # btrfs check /dev/data/btrfs > > # !! --check-data-csum > > > > The last command will fail as current btrfs-progs doesn't allow any > > option after parameter. > > > > > > Despite the requirement to distinguish global and subcommand > > option/parameter, is there any other requirement for such restrict > > option-first-parameter-last policy? > > I'd say that it's a common and recommended pattern. Getopt is able to > reorder the parameters so mixed options and non-options are accepted, > unless POSIXLY_CORRECT (see man getopt(3)) is not set. With the more > strict requirement, 'btrfs' option parser works the same regardless of > that.
I got bitten by this the other day. I put an option flag at the end of the line, after the mountpoint, and it refused to work. I would definitely prefer it if it parsed options in any position. (Or at least, any position after the group/command parameters). Hugo. > > If I could implement a enhanced getopt to allow more loose order inside > > subcomand while still can distinguish global option, will it be accepted > > (if it's quality is acceptable) ? > > I think it's not worth updating the parser just to support an IMHO > narrow usecase. -- Hugo Mills | Turning, pages turning in the widening bath, hugo@... carfax.org.uk | The spine cannot bear the humidity. http://carfax.org.uk/ | Books fall apart; the binding cannot hold. PGP: E2AB1DE4 | Page 129 is loosed upon the world. Zarf
signature.asc
Description: Digital signature
