Date: Tue, 10 Feb 1998 20:38:07 +0100 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sh jobs.c Message-ID: <19980210203807.25569@cons.org> In-Reply-To: <199802101742.EAA16027@godzilla.zeta.org.au>; from Bruce Evans on Wed, Feb 11, 1998 at 04:42:20AM %2B1100 References: <199802101742.EAA16027@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199802101742.EAA16027@godzilla.zeta.org.au>, Bruce Evans wrote:
[edited my patch as you requested]
> I checked an old draft of POSIX.2. The main points about signal handling
> seem to be:
>
> 1. For async commands, SIGINT and SIGQUIT from the keyboard shall be
> prevented from interrupting the command. Otherwise, signal handling
> shall be inherited from the shell's parent.
>
> Notes. This seems to require SIGINT and SIGQUIT not from the keyboard
> to not be handled specially. (How can the shell tell whether stdin is
> connected to _the_ keyboard? ;-). This doesn't specify handling of
> signals by the shell itself.
I'll try to get ahold of a newer POSIX document, maybe they became
more specific.
> 2. If the shell is waiting for a forground command, and a signal with a
> trap handler is received, then "the trap shall not be executed until
> after the foreground command has been completed".
>
> Notes. Presumably, trapped signals are supposed to be received and not
> just ignored while waiting for a command. Your change breaks this in
> most cases, since the shell ignores SIGINT and SIGQUIT while waiting.
I agree that this is probably intended, but I'm not sure this is the
right thing to do.
Suppose I have $EDITOR set to a script like this:
#!/bin/sh
emacs -nw "$@"
somecleanup
or an application calls
system("emacs -nw ; somecleanup-in-shell")
The cleanup will not be run when the user uses SIGINT/SIGQUIT in
emacs, but it will be run when the user exits emacs without using
these signals.
In my opinion, if the user uses an application that uses SIGINT and
SIGQUIT for its own purposes (that means, using these signals is part
of normal program usage like any other keystroke is), then the
surrounding shell should not take any action based on the signals. No
matter if it is done synchonously or after the childs exits. The
script above should run the cleanup in any case.
Also, I would like to avoid waking up the shell everytime a signal
arrives.
/bin/csh behaves as you describe, BTW. I added a test for this to my suite.
> The SIGINT case still works, accidentally, when the foreground command
> is killed by a SIGINT. Then the shell forwards the signal to itself
> after it restores its signal catcher. This can probably be fixed
> by replacing the signal(..., SIG_IGN)'s by a sigprocmask(SIG_BLOCK,
> ...), etc. Signals will be delayed until they are unblocked after the
> command completes, but this is precisely what is wanted.
Hm, unless I'm convinced otherwise, this isn't what I want. It's fine
in the case that the child is killed by (did not catch) the signal,
though.
As you said, my version accidentally does exactly what I want for both
bases.
I'll answer the other points later, got to drive home now.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
cracauer@wavehh.hanse.de (batched, preferred for large mails)
Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980210203807.25569>