🚀 go-pugleaf

In article <8908232203.AA15814@comp.vuw.ac.nz> nickson@comp.vuw.ac.nz (Ray Nickson) writes:

|  Some time ago, during a discussion on what the switches to the `type'
|  command should be, Brian wrote something like:
|    I don't know why you're complaining that these switches are too long.
|    You should be complaining that you cannot do completion on them.
|  (sorry, I've junked the message containing the exact quote; from
|  memory, this was the general idea though).
|  
|  I awaited some reaction to this, before commenting myself, but none
|  forthcame.  Was it just a throwaway line or do you really have plans
|  in this direction?  Something like VMS's (horror!) command description
|  language so the shell can know about what sort of arguments each
|  command expects and can do completion (and globbing!) appropriately?
|  Such a thought has brought groans of derision from nearly every un*x
|  hacker I've spoken to, yet I've never heard a good argument against
|  it.
|  
|  Is there anything in the back (or the front!) of your mind(s)(*) in this
|  direction?

I've thought about completion some, and have come to the conclusion
that it would very useful to have command specific completion.  For
example, I would like completion of a directory in the "cd" command,
to scan all directories in the current CDPATH.  When I'm invoking gcc,
I would like it to know about the switches, etc.  Now, I don't mean
making bash know about every single command and such.  Rather, I think
it should be in the UNIX tradition, of foisting off the stuff to
pipelines.

I've come up with the following different ideas, which are all
variations on the same theme of allowing the user to have an arbitrary
process being able to specify completions:

    1)	Given a directory (pointed to by an environment variable)
	containing different executables, if a completion is
	requested, search the directory for a match of a file against
	the current command being formed (stripping off the directory
	prefixes), invoke the program in the directory with the item
	needing a completion, and read it's stdout for a list of
	completions.  If the program doesn't exist, the normal
	completion is done.

    2)	If desired (ie, through setting an environment variable), fork
	off a user defined program when bash starts up or when the
	environment variable is changed.  Stdin of the process is
	connected via a pipe to bash, as is stdout.  Bash would then
	send the current input line needing a completion to the child
	process, which would either send back an indication to use the
	default completions (say an empty line), or a list of possible
	completions (say one completion per line, followed by an empty
	line).

    3)	Same as #1, except invoke the program each time a completion
	is needed.
--
--
Michael Meissner, Data General.
Uucp:		...!mcnc!rti!xyzzy!meissner		If compiles were much
Internet:	meissner@dg-rtp.DG.COM			faster, when would we
Old Internet:	meissner%dg-rtp.DG.COM@relay.cs.net	have time for netnews?