On 2018年06月18日 20:02, David Sterba wrote: > 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?
Personally speaking, yes. > There are > movement shortcuts to jump by words, you get the previous command by > up-arrow. About the same number of keystrokes. Not really, normally just "!! <new options>", where I don't even need to move my fingers to arrow keys. (I'm all ears about extra bash shortcuts on this) > > 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. The biggest problem is, the behavior isn't even consistent across btrfs-progs. mkfs.btrfs accept such out-of-order parameters while btrfs not. And most common tools, like commands provided by coretutil, they don't care about the order. The only daily exception is 'scp', which I found it pretty unhandy. And just as Paul and Hugo, I think there are quite some users preferring out-of-order parameter/options. I also understand the maintenance burden, but at least let's try if there are better solution for this. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
