Skip to content

Diversity in Command Line Syntax

andychu edited this page Oct 18, 2018 · 13 revisions

Here I'm picking the worst cases. My point is not that we have to handle them -- it's that the shared grammar shouldn't prevent you from handling these cases.

bash itself has two options parsers

The long options have to appear BEFORE the short options.

Usage:  bash [GNU long option] [option] ...

bash --posix -x --<TAB> -- This should not complete any long options!

set builtin has +x and -o / +o takes arguments oddly

set +oeu pipefail is equivalent to

set +o pipefail +e +u (try it in bash)

When I type set +oeu <TAB> -- I should complete pipefail and not an arg.

find command

find . -type f -<TAB> -- what is valid in that case? How do you write a grammar for it?

echo builtin

It doesn't respect -- according to POSIX.

Go flags package

-strflag str is allowed, but -boolflag 0 isn't allowed. Must be -boolflag=0 for negation, or -boolflag / -boolflag=1 when it's true.

python -c terminates flag processing

python -c -s <TAB> --

python -c x -s <TAB> --

-s is not a flag; it's an argument, because -c terminates flag parsing.

zsh seems to get this right. (bash doesn't complete flags at all, so it doesn't apply.)

Clone this wiki locally