* strange xterm & zsh behaviour @ 1999-01-27 22:26 Drazen Kacar 1999-01-28 5:46 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-01-27 22:26 UTC (permalink / raw) To: zsh-workers [This message has also been posted.] I've noticed that zsh in xterm behaves very strange when I'm in OpenWindows or failsafe session. Control keys and arrow keys don't work any more. The shell just echos ^[[A (for example) instead of scrolling through the history list. Ctrl-C is being echoed as ^C and the shell doesn't prompt in a new line. With zsh in dtterm everything works fine. With ksh in xterm and "set -o emacs" ^P, ^N and ^C work as expected. tcsh and bash in xterm also work as expected. stty -a gives the same result for both dtterm and xterm. I think the same thing happens with zsh in rxvt and some other terminal emulators, but I can't check that right now. Hardware: Ultra 1 console & Sun's X terminals. OS: Solaris 2.6 & 7. I suppose this is a bug in zsh. Does somebody know how to correct it? -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: strange xterm & zsh behaviour 1999-01-27 22:26 strange xterm & zsh behaviour Drazen Kacar @ 1999-01-28 5:46 ` Bart Schaefer 1999-01-28 9:38 ` Drazen Kacar 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 1999-01-28 5:46 UTC (permalink / raw) To: Drazen Kacar, zsh-workers On Jan 27, 11:26pm, Drazen Kacar wrote: } Subject: strange xterm & zsh behaviour } } I've noticed that zsh in xterm behaves very strange when I'm in OpenWindows } or failsafe session. It would help to know which version of zsh. 3.0.5? } Control keys and arrow keys don't work any } more. The shell just echos ^[[A (for example) instead of scrolling } through the history list. Ctrl-C is being echoed as ^C and the shell } doesn't prompt in a new line. Sounds like something has stomped on the tty driver settings. What do you see if you give the "stty -a" command? Is the value of $TERM the correct one? Sun OSs have a nasty habit of copying the console tty settings to all newly opened psuedo-tty devices, which is what xterm uses for I/O. In the X11R6 xterm there's even a resource, XTerm*ttyModes, added just to address this issue. Or an appropriate stty command in an init file; ksh, bash, and tcsh may even already have such commands in /etc/profile or /etc/cshrc or whatever. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: strange xterm & zsh behaviour 1999-01-28 5:46 ` Bart Schaefer @ 1999-01-28 9:38 ` Drazen Kacar 1999-01-29 3:47 ` Drazen Kacar 0 siblings, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-01-28 9:38 UTC (permalink / raw) To: Bart Schaefer; +Cc: Drazen Kacar, zsh-workers Bart Schaefer wrote: > On Jan 27, 11:26pm, Drazen Kacar wrote: > } Subject: strange xterm & zsh behaviour > } > } I've noticed that zsh in xterm behaves very strange when I'm in OpenWindows > } or failsafe session. > > It would help to know which version of zsh. 3.0.5? Yes. I'm sorry I didn't include more details. I started writing complaint about xterm on comp.unix.solaris and then I checked ksh, just to see how it fails in the same way. But it didn't, so I checked the rest of the shells and then had to send a copy to zsh the mailing list. I was too much surprised to think. Here are the details (some of which are not needed): I'm using a box which has "Ultra 1 creator" written on it, with Solaris 7 in 64-bit environment. It's freshly installed and software that's not from Sun's CDs is either compiled by me or by one of my co-workers. We use Debian packaging system and run-away config files are out of the question. This also means that all of our packages are compiled on Solaris 2.6 in 32-bit environment. However, I've seen the same problem on Solaris 2.6 on consoles and some terribly old Sun's X terminals. I don't know what exactly runs on those terminals, but I'm pretty sure it all comes from Sun. Since I'm trying to bring this station into usable state (that is, get rid of the CDE), I'm currently in a failsafe session which gives me one dtterm (/usr/dt/bin/dtterm). All reports are about xterm (/usr/openwin/bin/xterm) started from the first dtterm. > } Control keys and arrow keys don't work any > } more. The shell just echos ^[[A (for example) instead of scrolling > } through the history list. Ctrl-C is being echoed as ^C and the shell > } doesn't prompt in a new line. > > Sounds like something has stomped on the tty driver settings. Yes, just like I was on a teletype. When I press ctrl-C, the only visible effect is echoing "^C" in the same line. However, the shell cancels the command, since pressing enter produces only a prompt in the next line, regardless of what I previously typed in. > What do you see if you give the "stty -a" command? These are with Sun's stty. I currently don't have GNU stty, but I can install it if need be. iispeed 89376 baud; ospeed 89360 baud; rows = 24; columns = 80; ypixels = 364; xpixels = 724; eucw 1:0:0:0, scrw 1:0:0:0 intr = ^c; quit = ^\; erase = ^h; kill = ^u; eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^q; stop = ^s; susp = ^z; dsusp = ^y; rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v; -parenb parodd cs8 cstopb hupcl cread -clocal loblk crtscts crtsxoff parext -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany ixoff -imaxbel isig icanon -xcase echo echoe echok -echonl noflsh -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3 Dtterm has the same values, except for pixel values and erase character :-) > Is the value of $TERM the correct one? Set to "vt100" in $HOME/.zshrc. This is an ugly habbit which has something to do with people who like to define horrors like "xterm-debian" and the like. Setting TERM to "xterm" doesn't change anything. Vi is usually good at bringing terminals to the sane state, but not in this case. > Sun OSs have a nasty habit of copying the console tty settings to all > newly opened psuedo-tty devices, which is what xterm uses for I/O. In > the X11R6 xterm there's even a resource, XTerm*ttyModes, added just to > address this issue. And something decided I need it. xrdb -query reports (among lots of trash): *ttyModes: erase ^H intr ^C kill ^U start ^Q stop ^S swtch ^@ susp ^Z Setting swtch to ^@ doesn't change anything. /usr/dt/app-defaults/C/Dtterm contains only cosmetics. The same is with /usr/openwin/lib/app-defaults/XTerm. > Or an appropriate stty command in an init file; ksh, bash, and tcsh may > even already have such commands in /etc/profile or /etc/cshrc or whatever. grep stty **/*(.) in /etc and /usr/dt/config doesn't produce a thing (except stty -istrip somewhere in /etc/skel.orig, but I think this isn't executed). Neither does "**/.*(.)". The only global config file is /etc/profile. Csh doesn't have global config (according to the man page). Other shells do, but the files do not exist on my system. There are .* init files in my home directory (created by useradd -m), but none of them contains interesting stuff. A friend of mine kind of solved the problem 4-5 months ago. Rxvt (the latest and greatest at the time) behaved just like xterm. When I asked him about his solution he couldn't remember the exact procedure, so I got something like "There is a fallback code for terminal settings in rxvt in case those weren't set by the system. I just removed the if clause and told it to always set them." Don't ask about details. Your guess is as good as mine. I remember I was trying to copy terminal settings from patched rxvt to xterm (using both Sun's and GNU stty), but to no avail. That's about it. Further quetions? -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: strange xterm & zsh behaviour 1999-01-28 9:38 ` Drazen Kacar @ 1999-01-29 3:47 ` Drazen Kacar 1999-01-29 9:16 ` PATCH: 3.1.5* & 3.0.5: " Peter Stephenson 0 siblings, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-01-29 3:47 UTC (permalink / raw) To: zsh-workers; +Cc: Bart Schaefer, Drazen Kacar Drazen Kacar wrote: > > } Control keys and arrow keys don't work any > > } more. The shell just echos ^[[A (for example) instead of scrolling > > } through the history list. Ctrl-C is being echoed as ^C and the shell > > } doesn't prompt in a new line. Here's the patch for zsh 3.0.5 which fixes that: --- init.c.orig Fri Jan 29 04:10:39 1999 +++ init.c Fri Jan 29 04:29:49 1999 @@ -328,11 +328,20 @@ zsfree(ttystrname); ttystrname = ztrdup("/dev/tty"); } +#ifdef ALL_PRAISE_SUN +/* xterm, rxvt and probably all terminal emulators except dtterm on + Solaris 2.6 & 7 have a bug. Applications are unable to open /dev/tty + or /dev/pts/<terminal number here> because something in Sun's STREAMS + modules doesn't like it. The open() call fails with EBUSY which + is not even listed as a possibility in the open(2) man page. + So we'll try to outsmart The Company. -- <dave@srce.hr> */ + if (SHTTY == -1 && isatty(0) && (ttystrname = ztrdup(ttyname(0)))) + SHTTY = movefd(dup(0)); +#endif if (SHTTY == -1) { zsfree(ttystrname); ttystrname = ztrdup(""); } - /* We will only use zle if shell is interactive, * * SHTTY != -1, and shout != 0 */ if (interact && SHTTY != -1) { I'll leave the job of defining ALL_PRAISE_SUN to the maintainers. It should be defined for Solaris 2.6 and above. In case Sun produces a patch which fixes this problem, SHTTY won't be -1 and the bug fix code won't be executed. Hopefully. -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-29 3:47 ` Drazen Kacar @ 1999-01-29 9:16 ` Peter Stephenson 1999-01-29 18:59 ` PATCH: (more) " Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Peter Stephenson @ 1999-01-29 9:16 UTC (permalink / raw) To: zsh-workers; +Cc: Drazen Kacar Drazen Kacar wrote: > Drazen Kacar wrote: > > > > } Control keys and arrow keys don't work any > > > } more. The shell just echos ^[[A (for example) instead of scrolling > > > } through the history list. Ctrl-C is being echoed as ^C and the shell > > > } doesn't prompt in a new line. > > Here's the patch for zsh 3.0.5 which fixes that: The code for 3.1.5 is similar, so the same ought to work. It's pretty much impossible to test in configure, and it'll only try it if it really needs it, so probably it's OK to have the code run for all OSes. The worst that can happen is that you get a read-only terminal, but the alternative is no terminal at all. I added a free for ttystrname to match the other bits. Any more comments? *** Src/init.c.tty Thu Dec 17 12:17:04 1998 --- Src/init.c Fri Jan 29 10:13:19 1999 *************** *** 309,314 **** --- 309,330 ---- zsfree(ttystrname); ttystrname = ztrdup("/dev/tty"); } + /* + * xterm, rxvt and probably all terminal emulators except dtterm on + * Solaris 2.6 & 7 have a bug. Applications are unable to open /dev/tty + * or /dev/pts/<terminal number here> because something in Sun's STREAMS + * modules doesn't like it. The open() call fails with EBUSY which + * is not even listed as a possibility in the open(2) man page. + * So we'll try to outsmart The Company. -- <dave@srce.hr> + * + * Presumably there's no harm trying this on any OS, given that + * isatty(0) worked but opening the tty didn't. Possibly we won't + * get the tty read/write, but it's the best we can do -- pws + */ + if (SHTTY == -1 && isatty(0) && (SHTTY = movefd(dup(0))) != -1) { + zsfree(ttystrname); + ttystrname = ztrdup(ttyname(0)); + } if (SHTTY == -1) { zsfree(ttystrname); ttystrname = ztrdup(""); -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-29 9:16 ` PATCH: 3.1.5* & 3.0.5: " Peter Stephenson @ 1999-01-29 18:59 ` Bart Schaefer 1999-01-29 19:08 ` Bart Schaefer 1999-01-30 5:54 ` Drazen Kacar 0 siblings, 2 replies; 17+ messages in thread From: Bart Schaefer @ 1999-01-29 18:59 UTC (permalink / raw) To: Peter Stephenson, zsh-workers; +Cc: Drazen Kacar On Jan 29, 10:16am, Peter Stephenson wrote: } Subject: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour } } The worst that can happen is that you get a read-only terminal, } but the alternative is no terminal at all. } } I added a free for ttystrname to match the other bits. Any more } comments? I think the following is better; apply it on top of Peter's patch. Besides testing fds 0 and 1 for read-write-ness before using them (when possible), it also prefers ttyname(SHTTY) to "/dev/tty" for the setting of the $TTY parameter. This patch DOES NOT resolve a related bug that I reported long ago: echo echo foo | zsh -i gets you an interactive prompt reading from the tty, and does not echo foo. On the other hand: echo echo foo | zsh +Z -i (that is, explicitly turn off zle) prints a prompt, executes "echo foo" and then exits (end of file). I think the second behavior is the correct one for both cases, and that it should not be necessary to use +Z. Index: Src/init.c =================================================================== --- init.c 1999/01/29 18:16:38 1.9 +++ init.c 1999/01/29 18:55:29 @@ -303,31 +303,45 @@ zsfree(ttystrname); if ((ttystrname = ztrdup(ttyname(0)))) SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY)); + /* + * xterm, rxvt and probably all terminal emulators except + * dtterm on Solaris 2.6 & 7 have a bug. Applications are + * unable to open /dev/tty or /dev/pts/<terminal number here> + * because something in Sun's STREAMS modules doesn't like + * it. The open() call fails with EBUSY which is not even + * listed as a possibility in the open(2) man page. So we'll + * try to outsmart The Company. -- <dave@srce.hr> + * + * Presumably there's no harm trying this on any OS, given that + * isatty(0) worked but opening the tty didn't. Possibly we won't + * get the tty read/write, but it's the best we can do -- pws + * + * Try both stdin and stdout before trying /dev/tty. -- Bart + */ +#if defined(HAVE_FCNTL_H) && defined(F_GETFL) +#define rdwrtty(fd) ((fcntl(fd, F_GETFL) & O_RDWR) == O_RDWR) +#else +#define rdwrtty(fd) 1 +#endif + if (SHTTY == -1 && rdwrtty(0)) { + SHTTY = movefd(dup(0)); + } } - if (SHTTY == -1 && - (SHTTY = movefd(open("/dev/tty", O_RDWR | O_NOCTTY))) != -1) { + if (SHTTY == -1 && isatty(1) && rdwrtty(1) && + (SHTTY = movefd(dup(1))) != -1) { zsfree(ttystrname); - ttystrname = ztrdup("/dev/tty"); + ttystrname = ztrdup(ttyname(1)); } - /* - * xterm, rxvt and probably all terminal emulators except dtterm on - * Solaris 2.6 & 7 have a bug. Applications are unable to open /dev/tty - * or /dev/pts/<terminal number here> because something in Sun's STREAMS - * modules doesn't like it. The open() call fails with EBUSY which - * is not even listed as a possibility in the open(2) man page. - * So we'll try to outsmart The Company. -- <dave@srce.hr> - * - * Presumably there's no harm trying this on any OS, given that - * isatty(0) worked but opening the tty didn't. Possibly we won't - * get the tty read/write, but it's the best we can do -- pws - */ - if (SHTTY == -1 && isatty(0) && (SHTTY = movefd(dup(0))) != -1) { + if (SHTTY == -1 && + (SHTTY = movefd(open("/dev/tty", O_RDWR | O_NOCTTY))) != -1) { zsfree(ttystrname); - ttystrname = ztrdup(ttyname(0)); + ttystrname = ztrdup(ttyname(SHTTY)); } if (SHTTY == -1) { zsfree(ttystrname); ttystrname = ztrdup(""); + } else if (!ttystrname) { + ttystrname = ztrdup("/dev/tty"); } /* We will only use zle if shell is interactive, * -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-29 18:59 ` PATCH: (more) " Bart Schaefer @ 1999-01-29 19:08 ` Bart Schaefer 1999-01-30 5:54 ` Drazen Kacar 1 sibling, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-01-29 19:08 UTC (permalink / raw) To: zsh-workers On Jan 29, 10:59am, Bart Schaefer wrote: } Subject: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh } } I think the following is better; apply it on top of Peter's patch. Incidentally, neither of these patches applies directly to 3.0.5, because the 3.0.5 code lacks the O_NOCTTY flag on the calls to open(). To add the O_NOCTTY to 3.0.5, also add at the end of Src/system.h the three lines #ifndef O_NOCTTY # define O_NOCTTY 0 #endif -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-29 18:59 ` PATCH: (more) " Bart Schaefer 1999-01-29 19:08 ` Bart Schaefer @ 1999-01-30 5:54 ` Drazen Kacar 1999-01-30 12:43 ` Peter Stephenson 1 sibling, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-01-30 5:54 UTC (permalink / raw) To: Bart Schaefer; +Cc: Peter Stephenson, zsh-workers, Drazen Kacar Bart Schaefer wrote: > I think the following is better; apply it on top of Peter's patch. Besides > testing fds 0 and 1 for read-write-ness before using them (when possible), > it also prefers ttyname(SHTTY) to "/dev/tty" for the setting of the $TTY > parameter. Since I don't have the latest zsh development source tree, could you integrate this one in: #ifdef TIOCNXCL if(open("dev/tty", O_RDWR) < 0 && errno == EBUSY) ioctl(0, TIOCNXCL, 0); #endif That will unlock terminal device (at least on Solaris) and something should really do that (preferrably the shell). TIOCNXCL is defined in termios.h. -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-30 5:54 ` Drazen Kacar @ 1999-01-30 12:43 ` Peter Stephenson 1999-01-30 12:51 ` Peter Stephenson 1999-01-30 13:29 ` PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour Drazen Kacar 0 siblings, 2 replies; 17+ messages in thread From: Peter Stephenson @ 1999-01-30 12:43 UTC (permalink / raw) To: Drazen Kacar, zsh-workers Drazen Kacar wrote: > Since I don't have the latest zsh development source tree, could you > integrate this one in: > > #ifdef TIOCNXCL > if(open("dev/tty", O_RDWR) < 0 && errno == EBUSY) > ioctl(0, TIOCNXCL, 0); > #endif > > That will unlock terminal device (at least on Solaris) and something > should really do that (preferrably the shell). TIOCNXCL is defined in > termios.h. You mean something like the following? I don't quite know how to test for this, since you can't be assured fd 0 is /dev/tty. Maybe the ioctl() on its own is enough. --- Src/init.c.tiocnxcl Sat Jan 30 13:29:37 1999 +++ Src/init.c Sat Jan 30 13:42:31 1999 @@ -300,6 +300,19 @@ /* Make sure the tty is opened read/write. */ if (isatty(0)) { +#ifdef TIOCNXCL + /* + * See if the terminal claims to be busy. If so, and fd 0 + * is a terminal, try and set non-exclusive use for that. + * This is something to do with Solaris over-cleverness. + */ + int tmpfd; + if (tmpfd = open("/dev/tty", O_RDWR) < 0) { + if (errno == EBUSY) + ioctl(0, TIOCNXCL, 0); + } else + close(tmpfd); +#endif zsfree(ttystrname); if ((ttystrname = ztrdup(ttyname(0)))) SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY)); ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-30 12:43 ` Peter Stephenson @ 1999-01-30 12:51 ` Peter Stephenson 1999-01-30 18:04 ` Bart Schaefer 1999-01-30 13:29 ` PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour Drazen Kacar 1 sibling, 1 reply; 17+ messages in thread From: Peter Stephenson @ 1999-01-30 12:51 UTC (permalink / raw) To: Drazen Kacar, zsh-workers Peter Stephenson wrote: > You mean something like the following? I don't quite know how to test > for this, since you can't be assured fd 0 is /dev/tty. Maybe the > ioctl() on its own is enough. sorrysorry... this time I've tested it. (I didn't realise I could on AIX, but TIOCNXCL does exist after all.) This replaces the one two minutes ago. --- Src/init.c.tiocnxcl Sat Jan 30 13:29:37 1999 +++ Src/init.c Sat Jan 30 13:49:09 1999 @@ -300,6 +300,19 @@ /* Make sure the tty is opened read/write. */ if (isatty(0)) { +#ifdef TIOCNXCL + /* + * See if the terminal claims to be busy. If so, and fd 0 + * is a terminal, try and set non-exclusive use for that. + * This is something to do with Solaris over-cleverness. + */ + int tmpfd; + if ((tmpfd = open("/dev/tty", O_RDWR | O_NOCTTY)) < 0) { + if (errno == EBUSY) + ioctl(0, TIOCNXCL, 0); + } else + close(tmpfd); +#endif zsfree(ttystrname); if ((ttystrname = ztrdup(ttyname(0)))) SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY)); -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-30 12:51 ` Peter Stephenson @ 1999-01-30 18:04 ` Bart Schaefer 1999-01-30 18:27 ` Drazen Kacar 1999-02-03 11:08 ` PATCH: 3.1.5-pws-6: ttys revisited Peter Stephenson 0 siblings, 2 replies; 17+ messages in thread From: Bart Schaefer @ 1999-01-30 18:04 UTC (permalink / raw) To: Drazen Kacar, zsh-workers On Jan 30, 1:51pm, Peter Stephenson wrote: } Subject: Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & } } Peter Stephenson wrote: } > You mean something like the following? I don't quite know how to test } > for this, since you can't be assured fd 0 is /dev/tty. Maybe the } > ioctl() on its own is enough. } } sorrysorry... this time I've tested it. (I didn't realise I could on } AIX, but TIOCNXCL does exist after all.) This replaces the one two } minutes ago. Misc. remarks: (For Drazen) Is it desirable to ALWAYS do this? For a backgrounded shell, calling ioctl() on a tty device will usually result in a SIGTTOU stopping the process. (For PWS et al.) Even if it should always be done, I think it'd be a good idea to move this code down the point where an attempt to open /dev/tty might be made anyway, so that it needn't be opened and closed more than once. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-30 18:04 ` Bart Schaefer @ 1999-01-30 18:27 ` Drazen Kacar 1999-01-30 20:41 ` Terminal initialization and (non-)interactive shells Bart Schaefer 1999-02-03 11:08 ` PATCH: 3.1.5-pws-6: ttys revisited Peter Stephenson 1 sibling, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-01-30 18:27 UTC (permalink / raw) To: Bart Schaefer; +Cc: Drazen Kacar, zsh-workers Bart Schaefer wrote: > (For Drazen) Is it desirable to ALWAYS do this? For a backgrounded shell, > calling ioctl() on a tty device will usually result in a SIGTTOU stopping > the process. Just for the first interactive shell on the terminal. Background shell doesn't fall in that category. But why should a background shell attempt to initialize the terminal? It seems to me that background shell shouldn't call that function. On a related matter, does subshell initialize terminal? > (For PWS et al.) Even if it should always be done, I think it'd be a good > idea to move this code down the point where an attempt to open /dev/tty > might be made anyway, so that it needn't be opened and closed more than > once. I thought it was at that point, but diff didn't provide enough context and I'm without sources. -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Terminal initialization and (non-)interactive shells 1999-01-30 18:27 ` Drazen Kacar @ 1999-01-30 20:41 ` Bart Schaefer 1999-02-01 0:50 ` Drazen Kacar 0 siblings, 1 reply; 17+ messages in thread From: Bart Schaefer @ 1999-01-30 20:41 UTC (permalink / raw) To: Drazen Kacar, zsh-workers On Jan 30, 7:27pm, Drazen Kacar wrote: } Subject: Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & } } Bart Schaefer wrote: } } > (For Drazen) Is it desirable to ALWAYS do this? For a backgrounded shell, } > calling ioctl() on a tty device will usually result in a SIGTTOU stopping } > the process. } } Just for the first interactive shell on the terminal. Background shell } doesn't fall in that category. But why should a background shell attempt } to initialize the terminal? It seems to me that background shell shouldn't } call that function. On a related matter, does subshell initialize terminal? Every zsh, foreground or background, calls init_io(), which in turn does all the tty initialization if isatty(0). There's no test for `interactive'. This is, arguably, wrong. Another init_io(), but this time only for interactive shells, happens if/when "exec < /dev/foo" is run and foo is a tty device. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Terminal initialization and (non-)interactive shells 1999-01-30 20:41 ` Terminal initialization and (non-)interactive shells Bart Schaefer @ 1999-02-01 0:50 ` Drazen Kacar 1999-02-01 1:24 ` Bart Schaefer 0 siblings, 1 reply; 17+ messages in thread From: Drazen Kacar @ 1999-02-01 0:50 UTC (permalink / raw) To: Bart Schaefer; +Cc: Drazen Kacar, zsh-workers Bart Schaefer wrote: > } Bart Schaefer wrote: > } > } > (For Drazen) Is it desirable to ALWAYS do this? For a backgrounded shell, > } > calling ioctl() on a tty device will usually result in a SIGTTOU stopping > } > the process. > Every zsh, foreground or background, calls init_io(), which in turn does all > the tty initialization if isatty(0). There's no test for `interactive'. > > This is, arguably, wrong. I did some checking on Solaris 7. TIOCNXCL is handled by ttcompat streams module, which provides 4BSD streams compatibility (struct sgttyb things). An ioctl(TIOCNXCL) call from background process succeeds in unlocking the terminal device. Man page doesn't say a thing about this, but I think it's safe to put it anywhere. I don't know about non-Solaris systems. Besides, isatty(0) for background shell [checked with (echo foo >/dev/tty)& ] doesn't return 1. -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Terminal initialization and (non-)interactive shells 1999-02-01 0:50 ` Drazen Kacar @ 1999-02-01 1:24 ` Bart Schaefer 0 siblings, 0 replies; 17+ messages in thread From: Bart Schaefer @ 1999-02-01 1:24 UTC (permalink / raw) To: zsh-workers On Feb 1, 1:50am, Drazen Kacar wrote: } Subject: Re: Terminal initialization and (non-)interactive shells } } An ioctl(TIOCNXCL) call from background process succeeds in unlocking } the terminal device. Man page doesn't say a thing about this, but I think } it's safe to put it anywhere. I don't know about non-Solaris systems. By the time I sent my second message, I wasn't referring just to TIOCNXCL any more; it's the whole terminal setup block in init_io() that is a problem. } Besides, isatty(0) for background shell [checked with (echo foo >/dev/tty)& ] } doesn't return 1. I'm not sure how that let you check it, but strace on my linux system shows that isatty(0) most definitely does return 1. Note that I'm not talking about background subshells -- I'm talking about `/usr/local/bin/zsh &`. attachtty() most definitely gets stopped with at SIGTTOU in any background shell that happens to call it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* PATCH: 3.1.5-pws-6: ttys revisited 1999-01-30 18:04 ` Bart Schaefer 1999-01-30 18:27 ` Drazen Kacar @ 1999-02-03 11:08 ` Peter Stephenson 1 sibling, 0 replies; 17+ messages in thread From: Peter Stephenson @ 1999-02-03 11:08 UTC (permalink / raw) To: zsh-workers ioctl for non-exclusive tty use: "Bart Schaefer" wrote: > (For PWS et al.) Even if it should always be done, I think it'd be a good > idea to move this code down the point where an attempt to open /dev/tty > might be made anyway, so that it needn't be opened and closed more than > once. That seems to be sensible. This patch will do the whole thing pretty cheaply: only the `if (SHTTY == -1 && errno == EBUSY)' is usually executed. --- Src/init.c.nxcl2 Mon Feb 1 15:28:02 1999 +++ Src/init.c Wed Feb 3 12:01:41 1999 @@ -301,22 +301,19 @@ /* Make sure the tty is opened read/write. */ if (isatty(0)) { + zsfree(ttystrname); + if ((ttystrname = ztrdup(ttyname(0)))) { + SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY)); #ifdef TIOCNXCL - /* - * See if the terminal claims to be busy. If so, and fd 0 - * is a terminal, try and set non-exclusive use for that. - * This is something to do with Solaris over-cleverness. - */ - int tmpfd; - if ((tmpfd = open("/dev/tty", O_RDWR | O_NOCTTY)) < 0) { - if (errno == EBUSY) + /* + * See if the terminal claims to be busy. If so, and fd 0 + * is a terminal, try and set non-exclusive use for that. + * This is something to do with Solaris over-cleverness. + */ + if (SHTTY == -1 && errno == EBUSY) ioctl(0, TIOCNXCL, 0); - } else - close(tmpfd); #endif - zsfree(ttystrname); - if ((ttystrname = ztrdup(ttyname(0)))) - SHTTY = movefd(open(ttystrname, O_RDWR | O_NOCTTY)); + } /* * xterm, rxvt and probably all terminal emulators except * dtterm on Solaris 2.6 & 7 have a bug. Applications are -- Peter Stephenson <pws@ibmth.df.unipi.it> Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour 1999-01-30 12:43 ` Peter Stephenson 1999-01-30 12:51 ` Peter Stephenson @ 1999-01-30 13:29 ` Drazen Kacar 1 sibling, 0 replies; 17+ messages in thread From: Drazen Kacar @ 1999-01-30 13:29 UTC (permalink / raw) To: Peter Stephenson; +Cc: Drazen Kacar, zsh-workers Peter Stephenson wrote: > You mean something like the following? I don't quite know how to test > for this, since you can't be assured fd 0 is /dev/tty. Maybe the > ioctl() on its own is enough. I think so. Thanks. > + * This is something to do with Solaris over-cleverness. What a nice name for an ugly bug. :-) -- .-. .-. Life is a sexually transmitted disease. (_ \ / _) | dave@srce.hr | dave@fly.cc.fer.hr ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1999-02-03 11:08 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-27 22:26 strange xterm & zsh behaviour Drazen Kacar 1999-01-28 5:46 ` Bart Schaefer 1999-01-28 9:38 ` Drazen Kacar 1999-01-29 3:47 ` Drazen Kacar 1999-01-29 9:16 ` PATCH: 3.1.5* & 3.0.5: " Peter Stephenson 1999-01-29 18:59 ` PATCH: (more) " Bart Schaefer 1999-01-29 19:08 ` Bart Schaefer 1999-01-30 5:54 ` Drazen Kacar 1999-01-30 12:43 ` Peter Stephenson 1999-01-30 12:51 ` Peter Stephenson 1999-01-30 18:04 ` Bart Schaefer 1999-01-30 18:27 ` Drazen Kacar 1999-01-30 20:41 ` Terminal initialization and (non-)interactive shells Bart Schaefer 1999-02-01 0:50 ` Drazen Kacar 1999-02-01 1:24 ` Bart Schaefer 1999-02-03 11:08 ` PATCH: 3.1.5-pws-6: ttys revisited Peter Stephenson 1999-01-30 13:29 ` PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour Drazen Kacar
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).