ksh88 vs Ultrix 4.0

[Chet Ramey]

In article <9101060449.AA07794 at lilac.berkeley.edu> lwv27 at 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 at ins.CWRU.Edu		My opinions are just those, and mine alone.