From: Vincent Stemen <zsh@hightek.org>
To: Zsh hackers list <zsh-workers@sunsite.dk>
Subject: Re: PATCH: (2) Re: FreeBSD compatability feature request
Date: Wed, 28 Apr 2004 21:16:29 -0500 [thread overview]
Message-ID: <20040429021629.GA16141@quark.hightek.org> (raw)
In-Reply-To: <12706.1083059939@csr.com>
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@research.att.com>
> > 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
next prev parent reply other threads:[~2004-04-29 2:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040417222222.GA27230@quark.hightek.org>
[not found] ` <21533.1082374109@csr.com>
2004-04-21 8:21 ` Vincent Stemen
2004-04-21 10:00 ` Peter Stephenson
2004-04-21 11:05 ` PATCH: (2) " Peter Stephenson
2004-04-22 8:59 ` Vincent Stemen
2004-04-22 9:59 ` Peter Stephenson
2004-04-22 10:17 ` Peter Stephenson
2004-04-22 16:09 ` Jos Backus
2004-04-23 5:30 ` Vincent Stemen
2004-04-23 9:56 ` Peter Stephenson
2004-04-27 3:56 ` Bart Schaefer
2004-04-27 9:58 ` Peter Stephenson
2004-04-29 2:16 ` Vincent Stemen [this message]
2004-04-30 21:26 ` PATCH: (3) " Peter Stephenson
2004-05-01 1:45 ` Vincent Stemen
2004-05-01 2:23 ` Vincent Stemen
2004-05-04 7:17 ` PATCH: (3) - FreeBSD compatability issue resolved Vincent Stemen
2004-05-04 9:28 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040429021629.GA16141@quark.hightek.org \
--to=zsh@hightek.org \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).