Deutsch   English   Français   Italiano  
<0bg9hk-j2r.ln1@ID-313840.user.individual.net>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Geoff Clare <geoff@clare.See-My-Signature.invalid>
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: <slrnv3fm5e.jrj.naddy@lorvorc.mips.inka.de>
	<v1ah87$l0a8$1@news.xmission.com> <v1gpdq$3me9$1@dont-email.me>
	<slrnv3v0m5.17e3.naddy@lorvorc.mips.inka.de>
	<v1ogll$rrf5$1@news.xmission.com>
	<slrnv3vr2g.1gfp.naddy@lorvorc.mips.inka.de>
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 <netnews@gclare.org.uk>