Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

[Tomi Ollila <tomi.ollila@iki.fi>]

On Mon, Apr 27 2020, Daniel Kahn Gillmor wrote:

> On Mon 2020-04-27 14:53:07 -0300, David Bremner wrote:
>> Quoting notmuch(1)
>>
>>    OPTION SYNTAX
>>        All options accepting an argument can be used with '='
>>        or ':' as a separator. For the cases where it's not ambiguous
>>        (in particular excluding boolean options), a space can also be
>>        used.
>
> This is a pretty twisty way to say what we mean.  Are there other cases
> besides boolean options?  If there are, perhaps it'd be clearer to say
> something like this for the last sentence:
>
>     Except for boolean options and other potential ambiguous cases, a
>     space can also be used as a separator.
>
> If there aren't, we could say:
>
>     Except for boolean options (which would be ambiguous), a space can
>     also be used as a separator.
>
> Alternately, we could deprecate using whitespace for all options,
> produce explicit warnings to stderr when whitespace appears on the next

was it so, that originally we did not support whitespace, but David
added that in some commit...

> release, remove the suggestion to use a whitespace separator from the
> documentation, and eventually phase it out entirely in some future
> release.

Alternatively we could check that next arg is (case-insensitively)
(subset of) 'true', 'false', 'yes', 'no', '0', '1', 't', 'nil'
(but not tpyoes of these ;) and in that case have that as an option
value...

... would that work better for human user who just wants to be
fluent on command line -- frontends can then always use = and option
values...

>         --dkg

Tomi