Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11558

Re: SIGINT handling

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: SIGINT handling
Date 2015-09-24 14:40 -0400
Message-ID <mailman.1750.1443120070.19560.bug-bash@gnu.org> (permalink)
References (5 earlier) <20150920161245.GA14980@chaz.gmail.com> <20150920194542.GB14980@chaz.gmail.com> <560054CE.6000208@case.edu> <20150921210755.GC5598@chaz.gmail.com> <20150922121808.GK25574@eeg.ccf.org>

Show all headers | View raw


On 9/22/15 8:18 AM, Greg Wooledge wrote:
> On Mon, Sep 21, 2015 at 10:07:55PM +0100, Stephane Chazelas wrote:
>> Maybe the test scenario was not clear:
>>
>> bash -c 'cmd; echo hi'
>>
>> is run from an interactive shell, cmd is a long running
>> application (the problem that sparked this discussion was with
>> ping and I showed examples with an inline-script calling sleep)
> 
> Just for the record, ping is the *classic* example of an incorrectly
> written application that traps SIGINT but doesn't kill itself with
> SIGINT afterward.  (This seems to be true on multiple systems -- at
> the very least, HP-UX and Linux pings both suffer from it.)
> 
> A loop like this works as expected:
> 
> while true; do
>   sleep 1
> done
> 
> A loop like this does not:
> 
> while true; do
>   ping -c 1 some.host     # or on HP-UX, ping some.host -n 1
> done

If you decide, as bash has, to allow the foreground job to determine what
to do with SIGINT, you have to cope with software like ping.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: SIGINT handling Chet Ramey <chet.ramey@case.edu> - 2015-09-24 14:40 -0400

csiph-web