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. > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
