Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Geoff Clare Newsgroups: comp.unix.shell Subject: Re: Cleaning up background processes Date: Mon, 13 May 2024 14:14:40 +0100 Lines: 43 Message-ID: <0bg9hk-j2r.ln1@ID-313840.user.individual.net> References: Reply-To: netnews@gclare.org.uk Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net ZpeUDm2L9ABk0ZwHAANqdgAC8bsnFTXHhHhL6ei0NKiKprhzLp X-Orig-Path: ID-313840.user.individual.net!not-for-mail Cancel-Lock: sha1:0rlMy515y1RcADg9SFdxXu3PUtc= sha256:KJj3iUcwcv2gN4H0uBXLV9PJ0p9ag4sdsHhwfR4iWhQ= User-Agent: Pan/0.154 (Izium; 517acf4) Bytes: 2555 Christian Weisgerber wrote: > Instead of > > foo & > > I can run > > (trap - INT; exec foo) & > > and indeed that seems to restore the default behavior, i.e., terminate > the process, for both FreeBSD sh and bash. Anybody see any problem > with that approach? It doesn't/didn't work in some shells, according the POSIX rationale (XRAT C.2.11 "Signals and Error Handling"): Historically, some shell implementations silently ignored attempts to use trap to set SIGINT or SIGQUIT to the default action or to set a trap for them after they have been set to be ignored by the shell when it executes an asynchronous subshell (and job control is disabled). This behavior is not conforming. For example, if a shell script containing the following line is run in the foreground at a terminal: (trap - INT; exec sleep 10) & wait and is then terminated by typing the interrupt character, this standard requires that the sleep command is terminated by the SIGINT signal. I don't know which shells were affected or whether any might still be in use (without the behaviour having been corrected). > I'd also be interested in historical insights how this "ignore SIGINT > for asynchronous processes" behavior came to be. That's how shells behaved before job control was invented. It was how you could interrupt a foreground process without the signal affecting background processes. -- Geoff Clare