I'm just using standard C getopt-long stuff. Perhaps most of the stuff you work with are using meatier/extended CLI parsing code?

I'm not sure there's anything I could even do to make that work without writing the whole parser myself. I can check.

I've not heard of anyone else using kubies having this problem btw. is this cli quoting an unusual form of providing the arguments or something?

I don't think so? I'm just doing like...

          command:
            - memcached
            - -o proxy_config=routelib.lua,proxy_arg=proxy.lua # This one errors
            - -u appuser
            - -c 10000 # max connections
            - -l *:11200 # This one errors
            - -l tag_e2e_:*:11201 # This one errors
            - --memory-limit=90

If this is all just standard stuff and it's what we get without a larger investment, I'm fine to close, it just really caught me off guard.

Yeah, looks like this is just a getopt_long side effect for optional string args (so like "-c 10000" works as expected)
https://cfengine.com/blog/2021/optional-arguments-with-getopt-long/ talks about a solution for this a bit, but it seems hacky. https://superuser.com/a/1652973 talks about this in mysql world with the somewhat infamous -p flag. I'm fine with this being around, but maybe it's worth trying to change some of the docs to mention this, really surprised me earlier today.

it seems super bizarre to me to quote commandline arguments like that. I'll still take a look before considering this closed though.

with "-l localhost:11211":

(gdb) p argv[0]
$8 = 0x7fffffffe1bc "/home/dormando/p/code/memcached/memcached-debug"
(gdb) p argv[1]
$9 = 0x7fffffffe1ec "-l localhost:11211"
(gdb) p argv[2]
$10 = 0x0

with -l localhost:11211

(gdb) p argv[0]
$11 = 0x7fffffffe1bc "/home/dormando/p/code/memcached/memcached-debug"
(gdb) p argv[1]
$12 = 0x7fffffffe1ec "-l"
(gdb) p argv[2]
$13 = 0x7fffffffe1ef "localhost:11211"

So when you quote it getopt is dealing with a longer substring and actually parses it slightly differently.

When I get the suboption in the quoted case, it looks like localhost:11211 which then fails to parse later on because we don't skip leading whitespace as we aren't expecting it.

Just pushed a fix for this to next since it seemed simple. Millions of installs and over decades and you're the first to point it out :) Thanks!

Pushed to next means you can try the next branch now or wait for the next tarball release (roughly monthly)