Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11558
| 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> |
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
Re: SIGINT handling Chet Ramey <chet.ramey@case.edu> - 2015-09-24 14:40 -0400
csiph-web