Diversity in Command Line Syntax

(Back to Shell Autocompletion)

Here I'm picking the worst cases. My point is not that we have to handle them -- it's that a 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 take "distant" arguments

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.

declare -p is a flag, but declare -r +x is an option

That is, some flags can be prefixed with + in addition to -.

find command is a recursive language

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

expr and test are also recursive languages

In expr, + can be the binary arithmetic operator, or it can be escaping !!

NOTE: If the standard is bash-style completions, then you don't really need to complete anything for expr. However, test should know where filenames are valid.

See also: Problems With the test Builtin: What Does -a Mean?

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

echo builtin

It doesn't respect -- according to POSIX. Maybe this is easy to express?