Path: utzoo!mnetor!uunet!husc6!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.os.misc
Subject: What should completion look like on Unix?
Message-ID: <476@athos.rutgers.edu>
Date: 20 Dec 87 19:25:16 GMT
References: <1971@cup.portal.com> <1169@nmtsun.nmt.edu> <588@kuling.UUCP> <871@rocky.STANFORD.EDU>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 62
To: andy@rocky.UUCP


>No you don't have exactly the same behavior.  You have recognition for
>command names and arguments that are file names.  TOPS-20 command parser
>provides recognition for arguments that aren't file names as well as
>those that are.  You can also ask it what arguments are legal.

There's a tradeoff here.  I recently went back to our DEC-20 system to
do a few things.  I found myself horribly frustrated that I couldn't
use completion for arguments unless the command was built into the
EXEC, and also that TOPS-20 does completion but doesn't have anything
like the tcsh feature of a key that causes the shell to list every
name starting with what you have typed so far.  On balance, I
concluded that I prefer tcsh to TOPS-20.  (I do agree about wanting
the same parsing features in all programs.)  The advantage of the
TOPS-20 style is that when the EXEC knows about the command, it can
handle parsing more intelligently than Unix.  The disadvantage is that
when it doesn't, it can't do anything for you at all.  Unfortunately
there is no way to tell the EXEC about new commands, short of writing
a parsing routine for the commands in assembly language.

I have a comment about the current tendency to write TOPS-20 command
emulation for Unix.  To me the most important thing about TOPS-20 is
that it provides its fancy parsing features consistently in both the
EXEC and programs.  The equivalent on Unix is to provide intelligent
Unix-oriented command processing consistently in the shell and all
programs.  Having a few applications that simulate TOPS-20 is *not* an
improvement, unless there is general agreement to move to that style.
I'd much rather see a Unix command processing convention adopted that
is a bit more consistent with existing Unix.  I suggest the following:

1) provide a subroutine for parsing file names that is consistent with
(probably stolen from) tcsh/4.3csh.  It would understand ~, and do
completion and listing (i.e. ESC and ^D from tcsh).  This would be
used by all new programs that want to get file names from a user, and
would be retrofitted into old programs as maintenance is done to them.
(The mail readers should probably be the highest priority.)  Lock the
people responsible for tcsh and Gnu emacs in a closet and don't let
them out until they agree on a single character to use for file name
completion (tcsh uses ESC, Emacs uses TAB).
  
2) provide a subroutine for parsing command keywords.  Although the
shell currently does not allow abbreviations, most recent Berkeley
programs (lpc, mail, ...) seem to be following the TOPS-20/VMS
convention of having longish command names and accepting any unique
abbreviation.  Again, all new programs and over time old programs
should all use this style.  The shell should switch to it for
interpreting the command name.  Long aliases should be provided
for the more cryptic existing commands (copy, rename, delete, type,
append, and print as aliases for cp, mv, rm, more, cat, and lpr).
(This could be done in many cases simply by creating hard links.)

3) consider modifying tcsh/4.3csh to read a file like
/etc/tcsh-templates to define commands for which more intelligent
argument processing would be done.  Write the code for doing this so
that it could be used by other programs as well.  One would want
the ability to describe the commonly-used types of arguments and
options.  Once this is done, we should start encouraging long
option names, which would presumably be processed as on TOPS-20/VMS.
But please, start them with -, not /.  Let's not simulate TOPS-20.
I am also less than enthusiastic about making all of our command
processors go into cbreak mode so they can understand ?.  I think
the tcsh approach of activating immediately on ESC and ^D is quite
reasonable.