From owner-freebsd-current Tue Feb 10 14:00:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23758 for current-outgoing; Tue, 10 Feb 1998 14:00:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cons.org (knight.cons.org [194.233.237.86]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23737 for ; Tue, 10 Feb 1998 14:00:08 -0800 (PST) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.5/8.7.3) id XAA00479; Tue, 10 Feb 1998 23:01:29 +0100 (CET) Message-ID: <19980210230129.52530@cons.org> Date: Tue, 10 Feb 1998 23:01:29 +0100 From: Martin Cracauer To: Bruce Evans Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sh jobs.c References: <199802101742.EAA16027@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199802101742.EAA16027@godzilla.zeta.org.au>; from Bruce Evans on Wed, Feb 11, 1998 at 04:42:20AM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [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 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