[huhtenberg]

(edit) There is a bit of terminology substitution going on in linked article. Command line interface is a shell. That's where one types the commands. Calling command options and arguments an interface may be technically correct, but it is not what is conventionally understood under a term of CLI.

---

Speaking from an experience writing CLIs for configuration-heavy embedded devices, the key design element of a functional CLI is a context-aware TAB expansion. This is what makes a CLI truly convenient for routine use.

For example, if a mysql shell was smarter, it would've been allowing this:

  > use p<tab><enter>                   expands to "use production"
  > show c<tab> s<tab><tab><enter>      expands to "show columns from secondary"
  > select * f<tab> s<tab><tab> ...     expands to "select * from secondary ..."

It would also be nice to make OS shell more aware of individual commands' options, and to allow for example:

  # ip addr <tab>        shows "ip addr add"
  # <tab>                shows "ip addr del"
  # <tab>                shows "ip addr"

This is possible through hardcoding these expansions into the shell, but that's not very elegant, is it? On the other hand allowing to integrate arbitrary commands with the shell in a generic way would require putting together some sort of interface/manifest contraption and it would most likely go against the very spirit of Unix simplicity. So catch 22 it is.

[mcantor]

I think the use of "interface" is sensible, if somewhat ambiguous on the surface. In this context, options & arguments are the interface to the utility, not the "CLI", which is the interface to the command line itself.

Context-aware tab completion is very doable in the unix world, actually; it's just a hassle on the part of the utility-writer. Have you ever noticed that if you add a new file "foo/bar/baz.py" to a mercurial repository and type "hg add fo<TAB>", it will autocomplete all the way to "foo/bar/baz.py", without stopping at each directory? This is because hg has overridden the default tab completion provided by bash and defined its own set of possibilities.

I wish it were easier to set up; I think if that were the case, we'd see a lot more utilities with spot-on tab completion.

[lysol]

If you switch to Postgres, psql (the commandline client) supports the features you're asking for. :)

[technomancy]

Command-line usability is at least 50% about tab completion.

[asolove]

zsh has an extensible command/expansion system much like what you are asking for, allowing users to implement plugins documenting how to autocomplete commands, options, and data types passed to options (files, yes/no, etc.). It is fantastical.