POSIX bashing

Curtis Yarvin cgy at cs.brown.edu
Wed Apr 10 13:39:15 AEST 1991


In article <3478 at unisoft.UUCP> greywolf at unisoft.UUCP (The Grey Wolf) writes:
>21 at smoke.brl.mil> <70319 at brunix.UUCP>
>Reply-To: greywolf at unisoft.UUCP (The Grey Wolf)
>Organization: Foo Bar and Grill
>Lines: 65
>
>/* <70319 at brunix.UUCP> by cgy at cs.brown.edu (Curtis Yarvin)
> * In article <3446 at unisoft.UUCP> greywolf at unisoft.UUCP (The Grey Wolf) writes:
> * >...as next to useless as one can get without removing, say,
> * >the "minimal" tty editing functions (erase, kill, intr, quit,
> * 
> * How many applications that you use keep the terminal in cooked mode?  If the
>
>What's gained by putting a raw-mode interface between you and the terminal?
>It's an extra process and a tty/pty pair.  Over a network that becomes
>redundant.  Besides that, for every layer you add, response does go down.
>Minimally, okay, but most times (*MOST*) I can notice the little bit of
>added sluggishness when I type on that extra layer.

Exactly!  But this is my point.  If cooked mode did not exist, you would not
have to use a pty.  Pty is there to fake cooked mode in the first place.
And your input might even be faster, because the application could use
something a little cleaner than the kernel's clists to process it. Or it
could use something big and heavy, like readline, and get more
functionality.  Either way, it would be up to the application, which is the
way it should be.

Personally, I like emacs-style history editing.  You prefer simple
erase-kill processing.  Isn't it better to get the choice out of the kernel,
and let each application decide what it wants?

There is only one reason I have seen for keeping cooked mode.  If you have an
external I/O processor which knows how to cook, it can save some work.  But
how many people actually have such a beast?

curtis



More information about the Comp.unix.wizards mailing list