Re: stopping "wait" in (sub)script ?

Re: stopping "wait" in (sub)script ?

[Peter Stephenson]

Andrei Tcherepanov wrote:
> I cannot stop such command
> 
> $ for i in `cat ss`
> for> do xvi $i &
> for> wait
> for> done

yup, same here on IRIX 5.3 with 3.1.2-test1.  The `cat ss` is
definitely necessary, there is no problem if it's replaced by a simple
list of values.  Weird.

We have
#define POSIX_SIGNALS 1
if that makes a difference.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: stopping "wait" in (sub)script ?

[Zoltan Hidvegi]

> > I cannot stop such command
> > 
> > $ for i in `cat ss`
> > for> do xvi $i &
> > for> wait
> > for> done
> 
> yup, same here on IRIX 5.3 with 3.1.2-test1.  The `cat ss` is
> definitely necessary, there is no problem if it's replaced by a simple
> list of values.  Weird.

OK, now I got it.  The fix looks really simple, and I do hope that this is
really al that's needed.  entersubshell changes the terminal process group
to the subshell's newly created process group, and the main shell does not
reattach the terminal after the foreground process exits.  The simplest way
to reproduce the bug is

(:); while true; do; done

Which causes an uninterruptible infinite loop.

It is really surprising that this bug remained hidden for such a long
time.  An interactive shell always looses the terminal after executinh any
foreground command, and it is only reattached when the hbegin is called to
get the next line from the terminal.  This was probably the reason that
sometimes ^C did not interrupt loops started from an interactive shell.

Zoltan


*** Src/jobs.c	1997/05/09 04:55:51	3.1.2.3
--- Src/jobs.c	1997/05/15 06:57:44
***************
*** 156,161 ****
--- 156,164 ----
  
      pgrp = gettygrp();           /* get process group of tty      */
  
+     if (isset(MONITOR) && pgrp == jn->gleader)
+ 	attachtty(mypgrp);
+ 
      /* is this job in the foreground of an interactive shell? */
      if ((jn->gleader == pgrp || (pgrp > 1 && kill(-pgrp, 0) == -1)) &&
  	!ttyfrozen && !val && !jn->stty_in_env)

Re: stopping "wait" in (sub)script ?

[Peter Stephenson]

Zoltan Hidvegi wrote:
> > > I cannot stop such command
> > > 
> > > $ for i in `cat ss`
> > > for> do xvi $i &
> > > for> wait
> > > for> done
> > 
> > yup, same here on IRIX 5.3 with 3.1.2-test1.  The `cat ss` is
> > definitely necessary, there is no problem if it's replaced by a simple
> > list of values.  Weird.
> 
> OK, now I got it.  The fix looks really simple, and I do hope that this is
> really al that's needed.

This doesn't seem to fix this particular bug here, it's still
uninterruptible.  On the other hand, replacing `cat ss` with $(<ss)
has always worked.  That doesn't leave much code in getoutput() to
make the difference.

> (:); while true; do; done

This bug has been fixed as you say, so the patch is right as far as it
goes.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: stopping "wait" in (sub)script ?

[Bart Schaefer]

On May 15, 11:07am, Peter Stephenson wrote:
} Subject: Re: stopping "wait" in (sub)script ?
}
} > > > $ for i in `cat ss`
} > 
} > OK, now I got it.  The fix looks really simple, and I do hope that this is
} > really al that's needed.
} 
} This doesn't seem to fix this particular bug here, it's still
} uninterruptible.  On the other hand, replacing `cat ss` with $(<ss)
} has always worked.  That doesn't leave much code in getoutput() to
} make the difference.

I think the problem must be in signal_suspend().  The only difference
between the two cases in getoutput() is that $(<ss) does an explicit
child_unblock(), whereas `cat ss` does it implicitly via child_suspend(0).

If you go look at signal_suspend(), you'll find a lot of #ifdefs for the
assorted signal handling variations.  I'll bet this problem is specific
to one or more of those variations.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: stopping "wait" in (sub)script ?

[Zoltan Hidvegi]

> On May 15, 11:07am, Peter Stephenson wrote:
> } This doesn't seem to fix this particular bug here, it's still
> } uninterruptible.  On the other hand, replacing `cat ss` with $(<ss)
> } has always worked.  That doesn't leave much code in getoutput() to
> } make the difference.
> 
> I think the problem must be in signal_suspend().  The only difference
> between the two cases in getoutput() is that $(<ss) does an explicit
> child_unblock(), whereas `cat ss` does it implicitly via child_suspend(0).
> 
> If you go look at signal_suspend(), you'll find a lot of #ifdefs for the
> assorted signal handling variations.  I'll bet this problem is specific
> to one or more of those variations.

No.  The problem is that $(...) does not enter the new process to the
process table.  $(<...) does not fork, so it is not surprising that it
works.  The problem is that `cat ss` forks, and does an entersubsh after
the fork().  When a process terminates the SIGCHLD handler calls
update_job, which should reattach the terminal, but it does not do that
since the terminated job was not in the process table so update_job() is
not even called :-(.  I'll try to figure out a better solution tonight
(by that time it'll be tomorrow in Europe).

Zoltan

Re: stopping "wait" in (sub)script ?

[Zoltan Hidvegi]

I wrote:
> No.  The problem is that $(...) does not enter the new process to the
> process table.  $(<...) does not fork, so it is not surprising that it
> works.  The problem is that `cat ss` forks, and does an entersubsh after
> the fork().  When a process terminates the SIGCHLD handler calls
> update_job, which should reattach the terminal, but it does not do that
> since the terminated job was not in the process table so update_job() is
> not even called :-(.

I checked bash, ksh and pdksh, and all run command substituion in the same
process group as the shell.  This is logical, since a command substitution
cannot be backgrounded, and it solvs all the problems I described above,
plus some more.  The patch below should be applied on the top of my
previous patch (it does not depend on it, it just fixes an other bug).
What's also fix is:

% trap 'echo TERM' TERM
% echo `sh -c 'kill -TERM $$'`
TERM

As you see, the TERM trap is executed although the sell did not receive the
term signal, only the command substitution process terminated.  This
happened with all signals, not just SIGTERM (funny that bash has the same
bug, although only with the INT signal).

In most places where MONITOR is unset the terminal signals are set to
defaul.  This does not seems to be necessary here.  This copies the ksh93
behavious (pdksh and bash simply hangs when ^Z is pressed during command
substitution).  I have no idea why zsh need to change the SIGPIPE handler
when MONITOR is changed.  Anyone who knows better, please explain.  I also
wonder if we should add these signal changes to dosetopt() when MONITOR is
(un)set.  Examining ksh, pdksh and bash it seems that an interactive shell
should get a new process group and attach the terminal to this process
group on startup and it shoud restore its original process group and
reattach the terminal to this process group upon exit or before exec.  Any
comments about this?  It would be helpful if someone could look up the
relevant informations from POSIX 2a UPE.

Zoltan


*** Src/signals.c	1997/05/08 07:16:47	3.1.2.4
--- Src/signals.c	1997/05/16 05:05:35
***************
*** 422,434 ****
  	    for (;;) {
  		if (pid == *procsubpid) {
  		    *procsubpid = 0;
! 		    if (WIFSIGNALED(status)) {
  			*procsubval = (0200 | WTERMSIG(status));
! 			if (WTERMSIG(status) == SIGINT)
! 			    kill(getpid(), SIGINT);
! 			else if (sigtrapped[WTERMSIG(status)])
! 			    dotrap(WTERMSIG(status));
! 		    } else
  			*procsubval = WEXITSTATUS(status);
  		    times(&shtms);
  		    goto cont;
--- 422,430 ----
  	    for (;;) {
  		if (pid == *procsubpid) {
  		    *procsubpid = 0;
! 		    if (WIFSIGNALED(status))
  			*procsubval = (0200 | WTERMSIG(status));
! 		    else
  			*procsubval = WEXITSTATUS(status);
  		    times(&shtms);
  		    goto cont;
*** Src/exec.c	1997/05/09 05:36:44	3.1.2.8
--- Src/exec.c	1997/05/16 06:31:45
***************
*** 2109,2116 ****
      child_unblock();
      zclose(pipes[0]);
      redup(pipes[1], 1);
      entersubsh(Z_SYNC, 1, 0);
-     signal_ignore(SIGTSTP);
      execlist(list, 0, 1);
      close(1);
      _exit(lastval);
--- 2109,2116 ----
      child_unblock();
      zclose(pipes[0]);
      redup(pipes[1], 1);
+     opts[MONITOR] = 0;
      entersubsh(Z_SYNC, 1, 0);
      execlist(list, 0, 1);
      close(1);
      _exit(lastval);
***************
*** 2233,2240 ****
  
      /* pid == 0 */
      redup(fd, 1);
      entersubsh(Z_SYNC, 1, 0);
-     signal_ignore(SIGTSTP);
      execlist(list, 0, 1);
      close(1);
      _exit(lastval);
--- 2233,2240 ----
  
      /* pid == 0 */
      redup(fd, 1);
+     opts[MONITOR] = 0;
      entersubsh(Z_SYNC, 1, 0);
      execlist(list, 0, 1);
      close(1);
      _exit(lastval);