Zsh Mailing List Archive
Messages sorted by:
Re: PATCH (and another bug report): Re: zsh script and SIGCONT
- X-seq: zsh-workers 9012
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT
- Date: Mon, 13 Dec 1999 12:00:01 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Sun, 12 Dec 1999 20:07:59 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> Even worse than this ... if you read the script with ". p2", then ^Z only
> stops the "sleep 1" and the loop keeps going. All three cases ought to
> behave the same as executing the loop at the top-level prompt.
> I spent a while trying to trace through this, but it's nearly impossible
> to use a debugger in combination with tty stop signals, and zsh's job
> control is one of those places where "reading zsh source code makes you
> go blind," as Tom Christiansen has said.
Yes, real fun, isn't it... sigh.
> I believe the script case has something to do with both zsh and sleep
> getting the TSTP (which zsh doesn't have a special handler for); zsh forks
> to background the entire while loop, and therefore the parent shell exits
> from the loop -- but so does the forked child, for reasons that I can't
> However, in the case of a script, zsh doesn't need to do any of this; the
> script can start and stop as its own process.
> So the following appears
> to fix the script case, but I still don't know what's going on with ".".
In line 725/726 in exec.c we explicitly turn the list_pipe handling
off if we are sourcing. Removing these two lines makes it work in the
way you (and I) expect it. However, this is an explicit test and since
I don't have any idea why we did that, I won't produce a patch for it
now. Mainly because I don't think I'll have the time today to find out
why we added this test... if anyone has the time to look in the
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: