[COFF] Other OSes?

Dan Cross crossd at gmail.com
Mon Jul 9 10:19:18 AEST 2018


On Sun, Jul 8, 2018 at 8:12 PM Perry E. Metzger <perry at piermont.com> wrote:

> On Sun, 8 Jul 2018 16:27:54 -0700 Bakul Shah <bakul at bitblocks.com>
> wrote:
> [snip]
> > 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.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20180708/0d3c0a9c/attachment.html>


More information about the COFF mailing list