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

[Ciprian Dorin Craciun <ciprian.craciun@gmail.com>]

On Mon, Apr 27, 2020 at 9:21 PM Tomi Ollila <tomi.ollila@iki.fi> 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.


I definitively skipped over that warning, mainly because I was reading
the man-page for the specific command (i.e. `notmuch-search`, etc.)
that don't feature that warning.

Please note that I understand "why" I get this behavior, and
definitively I agree that it's my fault.  However my initial report
was intended to find a way that new users don't shoot themselves in
the foot, especially since many will use `notmuch` from a script, and
sometimes they don't thoroughly check the arguments passed by the
user.



> > 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...


From a "correctness" point of view, this would be the best approach.
However I think it could be too late to introduce it, and it would
break too many integrations.



> > 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...


This would be perhaps the best approach.  However I don't think it
would solve the issues for integrators that would not see these
warnings in the logs, until it is too late.



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


Perhaps there could be an additional option (either on the command
line or in the configuration) that would apply "strict" checking, and
not letting any other form except `--argument=value`, including the
boolean flags, and failing loudly.

I think this third option would enable much safer integrations.

(BTW, this "strict" option could also apply to the parsing of the
search terms, which most of the time are under the control of the end
user.)

Ciprian.