lwv27@CAS.BITNET (01/06/91)
We have encountered such a peculiar problem with ksh88 that I was wondering how others are dealing with the problem. We were running an older version of ksh when Ultrix 4.0 came in. A new version (ksh88e) had arrived and so someone decided to bring it up as the default ksh. We had tested the new version under SunOS and things looked fine... 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. The cd generates a bell. The D deletes the current line! Of course, everyone wanted to blame ksh88e. Interestingly enough, when the older version of ksh was compiled under Ultrix 4.0, it had the same behavior. Even more interesting was the fact that when we took the ksh 88e source, exactly as compiled on the Ultrix 4.0 system, and compiled it under Ultrix 2.2, everything worked fine. Anyone have any ideas on work arounds? -- Larry W. Virden UUCP: osu-cis!chemabs!lwv27 Same Mbox: BITNET: lwv27@cas INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 America Online: lvirden
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.
pak@regent.e-technik.tu-muenchen.dbp.de (Peter A. Krauss) (01/08/91)
chet@odin.INS.CWRU.Edu (Chet Ramey) writes: >Typeahead with Ultrix [34].? and termios is totally broken. I got the same problems with ksh88b and Ultrix 3.1. My solution: don't use termios(4) or termio(4), but use tty(4). mfg Peter -- +----------------------------------------------------------+ | Peter A. Krauss: pak@regent.e-technik.tu-muenchen.dbp.de | | pak@regent.e-technik.tu-muenchen.de | +----------------------------------------------------------+