Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pur-phy.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!eagle!mhuxl!ihnp4!inuxc!pur-ee!CS-Mordred!Pucc-H:Physics:crl
From: Pucc-H:Physics:crl@CS-Mordred.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Disgusting kernel hack
Message-ID: <1151@pur-phy.UUCP>
Date: Tue, 17-Jan-84 16:35:39 EST
Article-I.D.: pur-phy.1151
Posted: Tue Jan 17 16:35:39 1984
Date-Received: Wed, 18-Jan-84 07:43:33 EST
References: <18@isrnix.UUCP> <1193@mit-eddie.UUCP>
Organization: Purdue University Physics Dept.
Lines: 20

Of course, a 'more' filter fails for programs that detect if their
stdout is a pipe ('ls' comes quickly to my mind).

On a totally different subject, has anyone ever thought of a
new method of setting tty modes?  A few friends and I have discussed
the benefits of having (some) tty modes be process-dependent.  For
example, if you are in some program that sets (or resets, I can never
remember which) CRMOD, or RAW, and then something else writes to you
(a background process, another user, network daemon), then \n's aren't
changed to \r\n's, and so it totally disrupts the message and your
screen.  If the CRMOD (or a new equivalent mode) were process-dependent,
then the output would be ok.  There is also the benefit of not having
to catch signals and reset modes just to do some simple things, such
as a "Type any character to continue" type behavior.

Comments?

Charles LaBrec
UUCP:		pur-ee!Physics:crl, purdue!Physics:crl
INTERNET:	crl @ pur-phy.UUCP