Date: Tue, 10 Feb 1998 23:01:29 +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: <19980210230129.52530@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
[continuing my last mail] > 3. If the shell is waiting (via the wait command) for a background > command, then the wait command shall exit immediately on receipt of > a signal, and then the trap shall be executed. > > Notes. This is very broken in all versions of sh. Both the command > and the wait builtin seem to ignore all keyboard signals. It works > in bash. They ignore the signals only when handlers are installed. I added this to the tests and see if I can fix this. This is one reason more why I wouldn't like a solution that forces a user to trap a signal in a script where he uses a signal-catching program like emacs. i.e.: #!/bin/sh trap '' 2 trap '' 3 emacs -nw cleanup where he can't be sure to get his cleanup done without the traps. I don't want this anyway, but if the wait comman dis broken in this case, it is even worse. > 4. For subshells, traps caught by the shell shall be set to the default > values and traps ignored by the shell shall be ignored by the command. > > Notes. "the default values" doesn't seem to be specified. It presumably > means that the corresponding signals are set to SIG_DFL. The initial > state of trap handlers doesn't seem to be specified anywhere. I think > this means that sh's handling of signals is already correct, but bash's. > handling of subshells is incorrect. If you want to set the signal > handling portably, then you must use `trap'. This makes sense, since > changing from from SIG_DFL to SIG_IGN is easy, while changing from SIG_IGN > to SIG_DFL is impossible (the best you can do is attempt to kill the shell > from the trap handler) and wrong if anything except the shell set SIG_IGN. > Examples (where catchint exits normally when killed by SIGINT): > > (a) while :; do catchint; done # interactive > > The shell may be killed by a SIGINT. To ensure the usual handling, you > must use "trap '' SIGINT". It is not an error for the shell to ignore > SIGINT. (?) Sorry, you lost me. Did you mean "The LOOP my be killed by a SIGINT". The interactive shell shouldn't exit, no? If you do do trap '' 2 while :; do catchint; done You'll get completely runaway behaviour, you can't get rid of this loop any way. Even SIGSTOP won't work since it will usually be caught by the catchint process. > (b) #!/bin/sh > while :; do catchint; done > > Same as (a). "the default values" in for the trap handlers are not > specified to be different for interactive shells. (?) > > (c) #!/bin/sh > (while :; do catchint; done) > > Now there is a subshell. It must be killed by SIGINT. (?) For me (our sh and bash), the whole script (outer shell, inner shell, catchint) is terminated on SIGINT. It's the way it should be, IMHO. > (PR1206) /bin/sh -c "trap '' SIGINT; emacs" > > The command must be written something like this to ensure ignoring of > SIGINT. Is this your conclusion from this? > 4. For subshells, traps caught by the shell shall be set to the default > values and traps ignored by the shell shall be ignored by the command. What exactly do they mean by "command"? Does sh -c count as subshell? I think I'll have to sleep over it. 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?19980210230129.52530>