strange xterm & zsh behaviour

strange xterm & zsh behaviour

[Drazen Kacar]

[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

Re: strange xterm & zsh behaviour

[Bart Schaefer]

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

Re: strange xterm & zsh behaviour

[Drazen Kacar]

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

Re: strange xterm & zsh behaviour

[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

PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Peter Stephenson]

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

PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Bart Schaefer]

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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Bart Schaefer]

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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Peter Stephenson]

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));

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Peter Stephenson]

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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Bart Schaefer]

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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Drazen Kacar]

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

Terminal initialization and (non-)interactive shells

[Bart Schaefer]

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

Re: Terminal initialization and (non-)interactive shells

[Drazen Kacar]

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

Re: Terminal initialization and (non-)interactive shells

[Bart Schaefer]

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

PATCH: 3.1.5-pws-6: ttys revisited

[Peter Stephenson]

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

Re: PATCH: (more) Re: PATCH: 3.1.5* & 3.0.5: Re: strange xterm & zsh behaviour

[Drazen Kacar]

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