zsh-workers
 help / color / mirror / code / Atom feed
* BUG: backgrounding zsh does bad tty stuff
@ 2000-02-12  5:03 Geoff Wing
  2000-02-12  5:58 ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Geoff Wing @ 2000-02-12  5:03 UTC (permalink / raw)
  To: zsh-workers

Heyla,

% zsh-3.0.7 -f
% echo $SHLVL
2
% zsh-3.0.7 -f &
[1] 19784
% foo   # type two characters
zsh: error on TTY read: Input/output error

[1]  + exit 1     zsh-3.0.7 -f
% echo $SHLVL
2

Same with 3.1.6-dev-17
Anyone else getting this?  Also, with other options it will cause the parent
shell to exit as well.  And lots of other bad stuff.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: BUG: backgrounding zsh does bad tty stuff
  2000-02-12  5:03 BUG: backgrounding zsh does bad tty stuff Geoff Wing
@ 2000-02-12  5:58 ` Bart Schaefer
  2000-02-12 12:17   ` PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff) Geoff Wing
  0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2000-02-12  5:58 UTC (permalink / raw)
  To: mason, zsh-workers

On Feb 12,  5:03am, Geoff Wing wrote:
} Subject: BUG: backgrounding zsh does bad tty stuff
}
} Heyla,
} 
} % zsh-3.0.7 -f
} % echo $SHLVL
} 2
} % zsh-3.0.7 -f &
} [1] 19784

I immediately get

[1]  + suspended (tty output)  zsh -f

at this point, even with "stty -tostop".  Linux won't let any process
but the tty group leader poke settings into the tty driver.

What operating system are you using?

However, what did you expect?  "zsh -f" has no idea that it's in the
background, and attempts to start up ZLE as usual.  That's going to
play havoc with the parent shell's tty driver if the OS will let it
get away with it.

There's even a loop in init.c:init_io() where zsh repeatedly attempts to
force itself to be the tty foreground process, sending the pgrp leader
a SIGTTIN and then attempting to grab the tty.  Not pretty, but it has
been there for a very long time.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff)
  2000-02-12  5:58 ` Bart Schaefer
@ 2000-02-12 12:17   ` Geoff Wing
  2000-02-12 18:00     ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Geoff Wing @ 2000-02-12 12:17 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Bart Schaefer wrote about Re: BUG: backgrounding zsh does bad tty stuff:
:On Feb 12,  5:03am, Geoff Wing wrote:
:} Subject: BUG: backgrounding zsh does bad tty stuff
:} % zsh-3.0.7 -f
:} % echo $SHLVL
:} 2
:} % zsh-3.0.7 -f &
:} [1] 19784
:
:I immediately get
:[1]  + suspended (tty output)  zsh -f

:What operating system are you using?

NetBSD/i386 (current)

:However, what did you expect?

I expected to get what you got. 

:There's even a loop in init.c:init_io() where zsh repeatedly attempts to
:force itself to be the tty foreground process, sending the pgrp leader
:a SIGTTIN and then attempting to grab the tty.  Not pretty, but it has
:been there for a very long time.

Yes, since 2.2. Note that bash (2.03) has something similar but bash still
works properly.
My problem is that zsh gets past that loop when it should be stuck there.
This seems to fix it for me:  we shouldn't be making ourself the process
group leader for the terminal until our parent has told has we're really
the process group leader.
Also, I don't know why the sleep(1) is in there.  It should hang on the
killpg() - though it may be needed to compensate for some other weird
occurrence and possibly shouldn't be taken out?

*** Src/init.c.org	Tue Jan 25 06:25:59 2000
--- Src/init.c	Sat Feb 12 23:13:02 2000
***************
*** 394,403 ****
  #ifdef JOB_CONTROL
      /* If interactive, make the shell the foreground process */
      if (opts[MONITOR] && interact && (SHTTY != -1)) {
- 	attachtty(GETPGRP());
  	if ((mypgrp = GETPGRP()) > 0) {
  	    while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) {
- 		sleep(1);
  		mypgrp = GETPGRP();
  		if (mypgrp == gettygrp())
  		    break;
--- 394,401 ----
***************
*** 408,413 ****
--- 406,412 ----
  	    opts[MONITOR] = 0;
      } else
  	opts[MONITOR] = 0;
+     attachtty(GETPGRP());
  #else
      opts[MONITOR] = 0;
  #endif

-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff)
  2000-02-12 12:17   ` PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff) Geoff Wing
@ 2000-02-12 18:00     ` Bart Schaefer
  2000-02-13  5:22       ` Geoff Wing
  0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2000-02-12 18:00 UTC (permalink / raw)
  To: Geoff Wing; +Cc: zsh-workers

On Feb 12, 11:17pm, Geoff Wing wrote:
} Subject: PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stu
}
} :There's even a loop in init.c:init_io() where zsh repeatedly attempts to
} :force itself to be the tty foreground process
} 
} My problem is that zsh gets past that loop when it should be stuck there.
} This seems to fix it for me:  we shouldn't be making ourself the process
} group leader for the terminal until our parent has told has we're really
} the process group leader.

If the parent has made zsh the tty group leader -- note we're testing
ttpgrp == mypgrp -- then why would zsh need to make itself the tty group
leader?  It doesn't make sense to me to call attachtty() *after* we've
already verified that zsh is the tty group leader.

Perhaps what you mean is that we should wait for our parent to put us in
our own process group before attempting to make that group the tty group?

That isn't what your patch accomplishes, though.

} Also, I don't know why the sleep(1) is in there.

Note that we call GETPGRP() both before and after the sleep(1).  The
sleep is there to give the parent a chance to assign zsh to its own
group, i.e., have the OS context-switch to the parent and back before
we attempt GETPGRP() the second time.

Try this patch instead of 9692.  The difference that I see with the
patch below is that instead of

[1]  + suspended (tty output)  Src/zsh -f

with zsh stopped in ioctl() (according to gdb), I instead get

[1]  + suspended (tty input)  Src/zsh -f

with zsh stopped in its own call to killpg() -- which I think is the
desired behavior.

Index: Src/init.c
===================================================================
@@ -399,11 +399,12 @@
 #ifdef JOB_CONTROL
     /* If interactive, make the shell the foreground process */
     if (opts[MONITOR] && interact && (SHTTY != -1)) {
-	attachtty(GETPGRP());
 	if ((mypgrp = GETPGRP()) > 0) {
 	    while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) {
-		sleep(1);
+		sleep(1);	/* give parent time to change pgrp */
 		mypgrp = GETPGRP();
+		if (mypgrp == mypid)
+		    attachtty(mypgrp);
 		if (mypgrp == gettygrp())
 		    break;
 		killpg(mypgrp, SIGTTIN);

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff)
  2000-02-12 18:00     ` Bart Schaefer
@ 2000-02-13  5:22       ` Geoff Wing
  0 siblings, 0 replies; 5+ messages in thread
From: Geoff Wing @ 2000-02-13  5:22 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Bart Schaefer wrote about Re: PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff):
:Perhaps what you mean is that we should wait for our parent to put us in
:our own process group before attempting to make that group the tty group?

Yes, though the whole thing reeks anyway.  Your patch does a more appropriate
job, though in normal operation one is going to expect the parent to set
the pgrp appropriately before execing the child, thus all these 
GETPGRP() calls may be somewhat excessive - I haven't thought through all
the possible permutations yet (not to mention broken systems) so I think
I'll stay with your patch for now. 

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2000-02-13  5:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-12  5:03 BUG: backgrounding zsh does bad tty stuff Geoff Wing
2000-02-12  5:58 ` Bart Schaefer
2000-02-12 12:17   ` PATCH: 3.1.6-dev-17 (Was: BUG: backgrounding zsh does bad tty stuff) Geoff Wing
2000-02-12 18:00     ` Bart Schaefer
2000-02-13  5:22       ` Geoff Wing

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