On Mon, Jun 18, 2018 at 07:40:44PM +0800, Qu Wenruo wrote: > > > 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.
With POSIXLY_CORRECT set, it expectedly won't work. With POSIXLY_CORRECT unset, it would work in general, but not for 'btrfs'. As this is per-application decision I find it ok, besides that I also find the 'options anywhere' pattern bad. Does it really save you that much time while typing the commands with new arguments? There are movement shortcuts to jump by words, you get the previous command by up-arrow. About the same number of keystrokes. New code needs to be tested, documented and maintained, that's the cost I find too high for something that's convenience for people who are used to some shell builtins. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
