Xref: utzoo comp.unix.shell:1186 comp.unix.ultrix:5767
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!odin!chet
From: chet@odin.INS.CWRU.Edu (Chet Ramey)
Newsgroups: comp.unix.shell,comp.unix.ultrix
Subject: Re: ksh88 vs Ultrix 4.0
Message-ID: <1991Jan7.194506.9836@usenet.ins.cwru.edu>
Date: 7 Jan 91 19:45:06 GMT
References: <9101060449.AA07794@lilac.berkeley.edu>
Sender: news@usenet.ins.cwru.edu
Reply-To: chet@po.CWRU.Edu
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
Lines: 50
Nntp-Posting-Host: odin.ins.cwru.edu

In article <9101060449.AA07794@lilac.berkeley.edu> lwv27@CAS.BITNET writes:
>We have encountered such a peculiar problem with ksh88 that I was
>wondering how others are dealing with the problem.

>What we discovered was that for some reason users were not able to access
>their history files and there were problems with some typing (lagging
>response time, etc.)  One workaround was to set viraw mode, which
>fixed some of the problems.  But now we had a problem with type ahead.
>And what a problem - we found if users type before the prompt returns,
>the output is buffered some place - to appear a command or two later!
>This sounds almost harmless - until you see the following:
>a user types a cc command.
>While waiting, they type a cd D.someplace without thinking.
>The cc command generates an error.
>Since the cd command doesnt execute, they go ahead and type
>vi file.c
>AFTER ENTERING VI, the letters "cd D.someplace" are typed as if the
>user typed them.

Typeahead with Ultrix [34].? and termios is totally broken.  I can't get
it to work with bash, either.  Here's a quick transcript:

cwjcc$ sleep 4
echo hi				<--- typeahead during sleep
cwjcc$				<--- bash can't read it 
cwjcc$ cat < /dev/tty		<--- but cat can?
echo hi
cwjcc$ sleep 4
echo hi
cwjcc$ cat -			<--- from stdin too?
echo hi

Using FIONREAD on a file descriptor opened on /dev/tty or a file descriptor
from fileno(stdin) returns the correct number of characters, but a read on
that file descriptor for that number of characters either blocks or fails
with EWOULDBLOCK.

If you run a command that plays with the tty modes, like `more', the text
will come out after that command exits.

When using the `native' (they're not; termios is native) BSD tty ioctls,
the problem does not show up.

Chet
-- 
Chet Ramey				``There's just no surf in
Network Services Group			  Cleveland, U.S.A. ...''
Case Western Reserve University
chet@ins.CWRU.Edu		My opinions are just those, and mine alone.