Re: PATCH (and another bug report): Re: zsh script and SIGCONT

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Dec 13, 10:25am, Zefram wrote:
} Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT
}
} 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.
} 
} They can't.  A while loop requested in the current shell *can't* be
} backgrounded after being started, any more than you could background
} a builtin.

Have you tried it lately?

The conclusion we reached was that if you explicitly suspend the loop, you
accept the same consequences as if you backgrounded it in the first place.
(Just as if you interrupted it with ^C.)  This was intended to apply only
to interactive shells (and now it does).

} The loop has to be able to affect shell variables and so
} on, which means it has to execute in the shell process.

That, is probably the reason for this:

On Dec 13, 12:00pm, Sven Wischnowsky wrote:
} 
} 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.

I can see where one should reasonably assume that a script read with `.'
is specifically intended to modify the state of the current shell, and
therefore should never be forked off once it has started.  (This begs
the question of whether ". script &" is ever reasonable, but we can't
do anything about that.)

So I was about to suggest that we should simply turn off MONITOR during
`.' and `source', since it's rather bizarre to have the loop keep going
leaving behind a trail of suspended jobs until the job table fills.
But then I tried in in bash -- where the lack of NOTIFY means that you
don't even find out about the string of suspended jobs until the loop
exits -- and now I'm not so sure.

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