Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: stopping "wait" in (sub)script ?
- X-seq: zsh-workers 3152
- From: Zoltan Hidvegi <hzoli@xxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx (Zsh hacking and development)
- Subject: Re: stopping "wait" in (sub)script ?
- Date: Thu, 15 May 1997 11:47:16 -0400 (EDT)
- In-reply-to: <970515035240.ZM381@xxxxxxxxxxxxxxxxxxxxxxx> from Bart Schaefer at "May 15, 97 03:52:39 am"
> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author