Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: (2) Re: FreeBSD compatability feature request



On Tue, Apr 27, 2004 at 10:58:59AM +0100, Peter Stephenson wrote:
> Bart Schaefer wrote:
> > On Apr 22, 11:17am, Peter Stephenson wrote:
> > }
> > } If anybody actually knows anything about all this, their views would be
> > } especially welcome.
> > 
> > This sounds like something to ask about on the <shell@xxxxxxxxxxxxxxxx>
> > list.
> 
> It's not so much the standard as implementing an alternative in a
> consistent way that I'm worried about.
> 
> However, there is a difference in the current implementation:
> 
> $ fn() { sleep 5; kill -USR1 $$; }
> $ trap 'echo USR1 fired' USR1
> $ fn & sleep 10
> 
> ksh (88), bash and Solaris sh wait till the end of the sleep before
> delivering the `USR1 fired' (and, where appropriate, sending the
> notification message).  In zsh they appear in the middle.  That's
> because the exiting background process gives a SIGCHLD and we don't care
> which child exits, we just go into end-of-job-processing mode, then
> return to wait for the foreground process when we find that's not the
> one that exited.
> 
> I don't know if this is important enough to worry about.

I tested this under /bin/sh on FreeBSD and it also behaves the same as
bash and the others.  Even though, unless I am missing something here,
zsh seems to have the most appropriate behavior.  I don't quite
understand why the others don't immediately process the signal.  As
long as you are not blocking the signal I would expect it to print the
'echo USR1 fired' message as soon as it receives the signal whether it
is in the middle of a sleep or any other command.  

Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
Read how Network Solutions (NSI) was involved in stealing our domain name.
http://www.InetAddresses.net



Messages sorted by: Reverse Date, Date, Thread, Author