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

[Daniel Kahn Gillmor]

On Mon 2020-04-27 22:21:36 +0300, Ciprian Dorin Craciun wrote:
> On Mon, Apr 27, 2020 at 9:21 PM Tomi Ollila <tomi.ollila at iki.fi> wrote:
>>> [dkg wrote:]
>>> 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.

this looks really ugly to me, in that some legitimate queries
(e.g. those that include terms like "true" or "1") might not be
accessible, unless the user supplies --booloption=true instead of
--booloption.

I mean, these are all slightly idiosyncratic corner cases, but this
particular corner case looks super ugly and hard to explain to me.  i'm
trying to imagine writing some example text that explains it for the man
page, and it comes out horribly complex!  If we can't explain it
succinctly in the manpage, should we be implementing it?

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

I've spent many years helping to maintain GnuPG now, and i'm pretty wary
of having contextually different modes of argument parsing and
interacting/intersecting arguments.  It also leads to some weird
ambiguities: if --strict is supplied on the command line, then does it
need to be first on the command line?  or could parsing the command line
turn out different if you tack on --strict at the end?  Seems like we'd
be injecting additional idiosyncracies to chase after the first.

One final way we could normalize everything and make it less
idiosyncratic, with shorter, simpler man pages: deprecate and then drop
the --booloption/--no-booloption mechanisms, requiring --booloption=true
or --booloption=false instead.  Once they're dropped, allow whitespace
between "--booloption true" and "--booloption false" just like every
other type of option.



in case it's not clear: I believe that "we have succinct and yet
complete man pages" is a convenient shorthand for "have we made this
command-line program behave in an understandable/usable way?"

               --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20200428/e45f430a/attachment.sig>