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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to