Option order-sensitivity can surprise users

[nh2]

I just spent an hour trying to figure out why

bupstash put / --one-file-system

didn't work as expected (it still recursed into /dev) until added some debug prints into the code and figured that

bupstash put --one-file-system /

works as expected. The order is important.

It makes sense because the syntax is bupstash put [OPTIONS] [TAG=VAL...] DIRS... so OPTIONS comes before DIRS... and in the first case it's apparently treating --one-file-system as a directory.

But this is still very surprising, because most tools accept options at the end (e.g. rsync, even though its man page also describes rsync [OPTION...] SRC... [DEST]), as do most CLI parsing libraries.

Could there be a way to make this less of a UX trap?

For example:

• Allowing flags anywhere in the command, requiring e.g. -- to force the end of option parsing (similar to how :: works now in bupstash put).

[andrewchambers]

It depends which systems you are most familiar with- I tend to prefer the stricter ordering, but I do think we could warn or error on files that begin with '-' but are not after -- to avoid confusion.

This issue is also due to our option parsing library - which needs a change anyway (to fully support non utf8-paths), so we could investigate replacements that behave differently.

[nh2]

error on files that begin with '-' but are not after -- to avoid confusion

I think this would work equally well: I don't care about how a program chooses to design its CLI, as long as it helps me prevent mistakes such as backing up /dev or supposed-to-be-ephemeral tmpfs secrets.