9 Jul
2018
9 Jul
'18
7:13 p.m.
On Sun, 8 Jul 2018 20:19:18 -0400 Dan Cross <crossd(a)gmail.com> wrote:
On Sun, Jul 8, 2018 at 8:12 PM Perry E. Metzger
<perry(a)piermont.com> wrote:
The shell autocompletion script parses the output. That's the
point of the facility. It lets you get a TOPS-20 style completion
model where you get completion and help on all options, but the shell
doesn't need to be given that information ad hoc, it gets it from the
program through the use of the --autocomplete flag.
On Sun, 8 Jul 2018 16:27:54 -0700 Bakul Shah
<bakul(a)bitblocks.com>
wrote:
[snip]
I read that article and it wasn't clear to me that the
`--autocomplete` argument sent anything back to the shell. 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
suppose you could use it with bash/zsh style completion script to
get something analogous to context-sensitive help,
That's the sole purpose of it.
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;
That's what it does, yes.
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.
In this case, the program is run and asked about completions. It's a
somewhat different mechanism, but Unix is a different operating
system, and in the modern world, the time involved is ignorable.
Perry
--
Perry E. Metzger perry(a)piermont.com