-
-
Notifications
You must be signed in to change notification settings - Fork 163
Autocompletion Use Cases
andychu edited this page Oct 28, 2018
·
11 revisions
(Back to Shell Autocompletion)
- Completing the shell language itself. The knowledge to do this is all in the shell binary.
- Completing variable names for
${v<TAB>}
. - Completing keywords like
for
,while
, etc. - Completing the shell's own builtins like
set -o <TAB>
. - In zsh: completing various glob modes.
- Completing variable names for
- Completing flags names and arguments. This info is inherently "upstream".
- ... for common tools, which can be grouped:
- GNU coreutils and family tend to use the same syntax.
bash_completion
treats them all the same. - tools in Go tend to use the
flags
package, which has a consistent syntax.
- GNU coreutils and family tend to use the same syntax.
- ... for unusual tools
-
Diversity in Command Line Syntax -- bash itself has a nonstandard flag syntax,
python -c
,test
, etc.
-
Diversity in Command Line Syntax -- bash itself has a nonstandard flag syntax,
-
Very large tools -- it would be nicer to reuse the work from upstream.
- git
- clang
- npm?
- NOTE: Completing file system paths is a special case of a flag argument. The behavior here may be configurable in the shell, e.g. case-sensitivity.
- ... for common tools, which can be grouped:
- Completing languages/DSLs within arguments.
- This is generally a harder problem than completing args, because it may require recursive parsing.
-
sed -e
-- completing all the one letter commands with descriptions, completing the one letter flags with descriptions (from Oliver Kiddle) -
ssh
-- this is equivalent to parsing all of shell! i.e. the OSH parser. (from Oliver Kiddle) awk
- Regexes? I always forget how spell character classes like
[[:space:]]
.
Notes:
- Shellac Protocol Proposal handles #2 and #3. #1 is up to the shell binary.
- It is not clear to me (andychu) if grammar-based approaches can handle #3 (in general).