On 2018年06月18日 19:34, 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.
But currently it doesn't work. Just as the example, btrfs check /dev/data/btrfs --check-data-sum won't work. It's different from a lot of other common programs. > >> 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. I'll try to use the getopt() and keeps the current structure if possible. Thanks, Qu >
signature.asc
Description: OpenPGP digital signature
