bob@tyranosaur.cis.ohio-state.edu (Bob Sutterfield) (09/05/89)
In an X11R3 xterm client running on a Sun (or anything else I've got to test with), when I say cat < /dev/tty the cat will wait indefinitely for me to type something. When I type a carriage return, that line is echoed. This continues until I type my eof character, when I get my shell prompt back. $status==0. In an xterm client running on a Pyramid, `cat < /dev/tty' exits immediately, returning me to my shell. $status==0. This is quite frustrating when running applications like the stock su or an FTP client, or any other that takes the easy way out and opens /dev/tty for reading. X11R3 xterm on most everything but a Pyramid works correctly in this respect. X10R4 xterm had exactly the same behavior: correct everywhere but on a Pyramid. (I had hoped the problem would go away in X11, but I guess not...) I'm not complaining about Pyramid's support or anything like that, because I'm running the MIT code and we haven't paid Pyramid for their commercial-grade bulletproof X port, so we don't have it. I'm just curious whether anyone has already solved this one and is willing to share their solution for free, or whether it's time to dive into a Pyramid xterm with dbx (again). Any clues?
bg@draken.nada.kth.se (Bj|rn Gr|nvall) (09/07/89)
Sorry if you already read this in comp.windows.x. [...] > This is quite frustrating when running applications like the stock su > or an FTP client, or any other that takes the easy way out and opens > /dev/tty for reading. > > X11R3 xterm on most everything but a Pyramid works correctly in this > respect. X10R4 xterm had exactly the same behavior: correct > everywhere but on a Pyramid. (I had hoped the problem would go away > in X11, but I guess not...) I don't think the problem is in xterm but rather in /dev/tty. Consider the behaviour of the following program when run under an xterm and `inside' a script command. draken-15> cat pyr.bug.c #include <fcntl.h> main() { char ch; int fd = open("/dev/tty", O_RDWR); if (fd == -1) perror("open failed"); if (write(fd, "foo\n", 4) != 4) perror("write failed\n"); if (read(fd, &ch, 1) != 1) perror("read failed\n"); } draken-16> cc pyr.bug.c draken-17> ./a.out foo read failed : Bad file number <--- Should not happen! draken-18> script Script started, file is typescript draken-1> ./a.out foo <-- Ok! draken-2> exit Script done, file is typescript draken-19> Does anybody know if this is fixed in 4.4c? Bj|rn Gr|nvall (Bjorn Gronvall) Royal Institute of Technology, NADA 100 44 Stockholm Sweden email: bg@nada.kth.se phone: +46-8-7909101 -- /Bj|rn.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/07/89)
bg@draken.nada.kth.se (Bj|rn Gr|nvall) writes: > [Bob Sutterfield reports problems with xterm and /dev/tty under X11R3. I don't think the problem is in xterm but rather in /dev/tty. Consider the behaviour of the following program when run under an xterm and `inside' a script command. Very interesting. It seems that /dev/tty doesn't like to be opened for read in general? This can't be the entirety of the problem, though, because /dev/tty works fine from a real terminal or a more ordinary pty running from telnet or rlogin, just not from inside an xterm window. Does anybody know if this is fixed in 4.4c? Assuming it's a bona fide bug with /dev/tty, no. That's what we're running. But I don't think I'm yet convinced yet that /dev/tty is at fault. -- Karl "We make men without [sentiment] and expect of them virtue and enterprise. We laugh at honour and are shocked to find traitors in our midst. We castrate and bid the geldings be fruitful." --Lewis
bg@draken.nada.kth.se (Bj|rn Gr|nvall) (09/07/89)
> Very interesting. It seems that /dev/tty doesn't like to be opened > for read in general? This can't be the entirety of the problem, > though, because /dev/tty works fine from a real terminal or a more > ordinary pty running from telnet or rlogin, just not from inside an > xterm window. Well, /dev/tty opens for reading but it is the call to read that fails. Shouldn't a file opened for reading be readable?? Maybe it is possible using some weird call to ioctl to put a file into this mode (I don't know), but then the errorstatus should not be "Bad file number" but rather something like "Illegal file mode". Also why does this not happen on other BSD derived systems? Bj|rn Gr|nvall (Bjorn Gronvall) Royal Institute of Technology, NADA 100 44 Stockholm Sweden email: bg@nada.kth.se phone: +46-8-7909101 -- /Bj|rn.