[nloomans]

I disagree with it being a minor issue. If I write a shell script around a program that accepts GNU-style arguments, I expect the following to be correct:

    ./cmd -a"$USER_CONTROLLED_DATA"

A program using this package would break that assumption, introducing a bug where this user-controlled data cannot start with an '='.

[duckerude]

I researched this for my own argument parser (https://github.com/blyxxyz/lexopt/issues/13) and concluded that it's a minor issue.

This syntax is supported by argparse and clap, the most popular argument parsers for Python and Rust respectively, and it seems to have caused almost no problems for them. It's a problem for the uutils implementation of cut, since `cut -d=` is common, but that's the only instance I could find after a long time scouring search engines and bug trackers and asking for examples.

If anyone does know of other examples or other places this has been discussed I'd love to hear it though, maybe I just haven't found them.

(Also, the more reliable way to write this in general is `-a "$USER_CONTROLLED_DATA"`, since that'll behave correctly if $USER_CONTROLLED_DATA is empty. As will `-a="$USER_CONTROLLED_DATA"` if you know the command supports it.)

[edoceo]

In the Gentoo world, sometimes you need to give an exact package name which looks like `=net-misc/foo-0.1.2-r1`. The exact match has to start with the '='.

[ucarion]

I think short options taking a value in the same argv (i.e. `-o=1` stuff) isn't a GNUism mostly because it's backwards-incompatible with POSIX. `=` is a valid getopt option character, `chmod` uses it.

That said, I think? 'nloomans means for USER_CONTROLLED_DATA to be a set of short flags, not flag values, as in:

    root@08e9950d5bfd:/# export USER_CONTROLLED_DATA=lh 
    root@08e9950d5bfd:/# ls -a"$USER_CONTROLLED_DATA"
    total 56K
    drwxr-xr-x   1 root root 4.0K Mar 23 16:51 .
    drwxr-xr-x   1 root root 4.0K Mar 23 16:51 ..
    [...]

Not that I've seen this in the wild before. But everyone's use of bash is a unique personal hell anyway.

[cb321]

Ha! I just said that. :-)

Anyway, one other alternative for the `cut` situation is to allow either ':' or '=' to optionally separate the key and the value. Then you can say `cut -d:=` or `cut -d=:` if you wanted to use either one. This is what https://github.com/c-blake/cligen does (for Nim, not Go).

[fragmede]

I'm sad docopt (http://docopt.org/ ) didn't get more uptake because I'm a fan of self-documenting code.

[cb321]

It is safer to just put in the space (much like you put in the quotes to be safe). Python's argparse will also accept but not require an `=` separator (maybe optparse, too - I haven't checked that one).

[mort96]

It's only "safer" because argp has this particular bug. It's safer for argp (or python's argument parser, for that matter) to not have surprising buggy features like this.