chet@odin.INS.CWRU.Edu (Chet Ramey) (01/08/91)
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.