Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: Input Line Editing
Message-ID: <1230@mcgill-vision.UUCP>
Date: 5 Aug 88 03:09:58 GMT
References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <9677@eddie.MIT.EDU> <1988Jul22.203037.9092@utzoo.uucp>
Organization: McGill University, Montreal
Lines: 64

In article <1988Jul22.203037.9092@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <6339@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
>> ... We have the line editor built into csh.  I maintain this is the
>> right thing to do...

(I didn't write the >> text, but I might have.  We, too, have editing
built into the csh, and I too maintain this is the right thing to have
done.  Not that it's the right ultimate solution, but that it's the
right thing to have done, given what we had to start with.)

> I trust you have put this into *all* the shells?  (Especially since
> the name of the shell which is closest to being a Unix-wide standard
> does not begin with "c".)

No, we don't have it in all the shells.  So?  Suppose I add a verbose
flag to, um, dd.  Does this now instantly leave me open to criticsm
because I didn't add the same flag to all other programs?

> Whatever happened to layers of abstraction?

Not workable at present.  Ideally, input editing should be divorced
from the shell.  *However*,

- The input editor must know whether it's talking to the shell or not.
   Primarily to keep input histories separate, secondarily to shift
   command sets (I, for example, want ^P as previous-line-of-history in
   the shell but SIGTSTP when running a program).

- The input editor must go away when the tty is in raw or cbreak mode.
   This means one ioctl per typed line in cooked mode (bearable) or per
   typed character in raw or cbreak (possibly bearable, but also
   possibly not).

- When speaking to the shell, the input editor must have access to
   things only the shell knows.  In particular, the shell's current
   directory, its current set of shell and environment variables and
   any bind commands that have been issued since the shell started.

None of these are insurmountable, given unlimited time to hack the
kernel (or extensive hacks to the shell, which amounts to merging the
shell and the input editor - see below).  However, very few, if any, of
us have this luxury.  And the only other programs we spend substantial
time typing at are editors, for which input line editing is
inappropriate (for those (few?) who use ed, there *is* ile).

Stop and think about it.  Are there any programs, besides the shell and
editors, that you spend much time typing to?  Of those, are there any
that do line-at-a-time input (as opposed to screen-oriented programs
like less, rogue, or hack)?  There certainly aren't in my case.

Now.  Tell me again, why was it wrong to put input editing into the
csh?  It solves the problem in a manageable amount of time, without
creating worse problems.  The only alternative I see is to build the
facilities of ile into the shell, so it is not only a shell but also a
full input editor for executed commands.  This may be workable, but I
suspect the use of a pty when unnecessary (eg, editors) will impose a
sometimes-unacceptable performance hit.  But if you want to try it,
feel free - a good shell rewrite plus general input editor would be a
very nice thing to have around.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu