9 Jul
2018
9 Jul
'18
8 a.m.
On Jul 8, 2018, at 5:19 PM, Dan Cross <crossd(a)gmail.com> wrote:
On Sun, Jul 8, 2018 at 8:12 PM Perry E. Metzger <perry(a)piermont.com> wrote:
On Sun, 8 Jul 2018 16:27:54 -0700 Bakul Shah <bakul(a)bitblocks.com>
wrote:
[snip]
It wasn't clear to me either. I looked at the clang webpage again
and all I see is autocompletion support for clang itself. [In a way
this points to the real problem of clang having too many options]
This sort of magic incantation is needed because
no one has bothered
to create a simple library for autocompletion & no standard
convention has sprung up that a program can use.
Yes, I know. That's exactly what I'm explaining. Read the URL above.
It describes a quite general mechanism for a program to convey to the
shell, without needing any special binary support, how autocompletion
should work.
I read that article and it wasn't clear to me that the `--autocomplete` argument
sent anything back to the shell. I suppose you could use it with bash/zsh style completion
script to get something analogous to context-sensitive help, but it relies on
exec'ing the command (clang or whatever) and getting output from it that someone or
something can parse and present back to the user in the form of a partial command line;
the examples they had seemed to be when invoking from within emacs and an X-based program
to build up a command. This is rather unlike how TOPS-20 did it, wherein an
image was run-up in the user's process (effectively, the program was exec'ed,
though under TOPS-20 exec didn't overwrite the image of the currently running program
like the shell) and asked about completions. The critical difference is that under TOPS-20
context-sensitive help and completions were provided by the already-runnable/running
program. In Unix, the program must be re-exec'd. It's not a terrible model, but
it's very different in implementation.
When we did cisco CLI support in our router product, syntax for all
the commands was factored out. So for example
show.ip
help IP information
show.ip.route
help IP routing table
exec cmd_showroutes()
show.ip.route.ADDR
help IP address
verify verify_ipaddr()
exec cmd_showroutes()
etc. This was a closed universe of commands so easy to extend.
Perhaps something similar can be done, where in a command src dir
you also store allowed syntax. This can be compiled to a syntax
tree and attached to the binary using some convention. The cmd
binary need not deal with this (except perhaps when help or verify
required cmd specific support).
I ended up replicating this sort of thing twice since then.