Xref: utzoo comp.unix.questions:15511 comp.unix.wizards:17545
Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cbmvax!ag
From: ag@cbmvax.UUCP (Keith Gabryelski)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Where Goeth the Line-editing?
Message-ID: <7564@cbmvax.UUCP>
Date: 8 Aug 89 00:07:40 GMT
References: <13303@bloom-beacon.MIT.EDU> <795@dms.UUCP>
Reply-To: ag@cbmvax.UUCP (Keith Gabryelski)
Organization: Commodore Technology, West Chester, PA
Lines: 42

To comp.unix.wizards since it seems more appropriate.

In article <795@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes:
>From article <13303@bloom-beacon.MIT.EDU>, by jik@athena.mit.edu
					       (Jonathan I. Kamens):
>>   In multics, it was possible to install a driver that lived at the
>> gateway between the actual terminal and user processes.  This driver
>> would intercept and process *all* input before sending it to the
>> process.  Therefore, if you wrote a line-editing driver and installed
>> it, it would work for *every* program on the system, without fail.
>> There were, of course, ways to turn off the line-editing features for
>> programs that needed character-by-character input.
>> 
>
>Actually, Un*x has this "feature" as well. At least, sort of. The
>concept of line disciplines was developed to address this issue (or
>other protocol handling requirements). Line discipline 0 is responsible
>for doing the input editing you get when doing normal (such as echo,
>backspace processing, line kill, signals, etc). It also does the stuff
>such as adding extra cr's, lf's, null's or other things in the output
>stream as so indicated by various stty flags. Line disciplines don't do
>the job as neatly as is desired (a better idea, STREAMS, was invented
>which does the job quite a bit better).

We actually just wrote a line discipline that emulates the TOPS-20
line discipline for our SYSV3.2 port to the Amiga (echoing only when
input was read), ^O, ^V, ^W, and no backspacing over your prompt.

I was going to add history and real command line editting, but finally
came to my senses that the kernel was just not the place for such a
user-configurable/messy thing.
	
The best suggestion I've heard is a daemon the user runs that gets
handed each character the user types and deals with them
and the canon buffer appropriately.

I did finally break down and added a last command hack but am sure
this will disappear when something better is found.

I am open to suggestions.

Pax, Keith