Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX bashing
Message-ID: <129131@uunet.UU.NET>
Date: 16 Apr 91 01:08:17 GMT
References: <3446@unisoft.UUCP> <3478@unisoft.UUCP> <1991Apr14.094953.12840@thunder.mcrcim.mcgill.edu>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 62

In article <1991Apr14.094953.12840@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>> But why put an extra layer there...?  You're not saving anything by
>> doing that, either, really.  And such a thing would be a lose on a
>> shell.  The one advantage I can see is that one could do convenient
>> things like defining both Backspace *AND* delete to be "delete", or
>> have both control-Z and control-P be "suspend" or whatever.

BTW, don't forget that cbreak and cooked mode are another layer
on top of raw mode, altho it is done in the kernel.

>Since I use a shell that does run in cbreak....

Me too. Mostly tcsh, but I'm comfortable with ksh too.

>The usefulness of such an interface promises to be as much a religious
>issue as editor wars or keyboard quality arguments.  So to throw my two
>cents into the fray....

Yeah, but maybe we can agree this time :-)

>I find it to be a major *win* in the shell.  Not just because I can
>define both \10 and \177 as "delete", though that capability is nice.

YES! Let many keys map to one function. One useful one is "break",
(or "newline") which sends the accumulated string up to the user.
A text editor might set all control characters to this and all
printables to self-insert.

>Much more important is the ability to edit the command-line at
>points other than the current end.  I occasionally have to use systems
>without such shells, so I have a constant basis for comparison.

And ain't it horrible? It makes my head hurt.

>A rough estimate is that using the shell I do, instead of a standard sh
>or csh, saves me perhaps ten minutes per day.

Which I promptly waste again reading/posting news :-)

>And the cost is minimal;
>another rough estimate places the cost at well under 1 cpu-second per
>day, and most of those cycles would otherwise be burnt in the idle
>loop.  No, it's unquestionably worth it.  For me.  (If you want to
>claim that shells running in cooked mode should be available, you won't
>get any argument out of me.)

My point is that I want my food well-done.

I think the real challenge is to put readline and termcap into the kernel.
By now, everyone's terminal should be ANSI and require no padding, so
simple line editing should be reasonable to do. Give names to the functions,
and allocate a keymap (or a pointer to the parent's, with copy on write
semantics) to each user.  Likewise, allocate a termcap structure.

There would be no context switching to allow user code to process
each keystroke as is done with cbreak mode. If the kernel did enuf
editing, the shell could run in cooked mode and still be usable.

Raw mode as always for programs that want to do everything.
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane