Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11534
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: SIGINT handling |
| Date | 2015-09-22 08:18 -0400 |
| Message-ID | <mailman.1586.1442924296.19560.bug-bash@gnu.org> (permalink) |
| References | (4 earlier) <20150920155219.GA8614@chaz.gmail.com> <20150920161245.GA14980@chaz.gmail.com> <20150920194542.GB14980@chaz.gmail.com> <560054CE.6000208@case.edu> <20150921210755.GC5598@chaz.gmail.com> |
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 You might already have been aware of this; I'm not sure. But in any case, it makes a tremendous different what "cmd" is in your example. You can't generalize it.
Back to gnu.bash.bug | Previous | Next | Find similar
Re: SIGINT handling Greg Wooledge <wooledg@eeg.ccf.org> - 2015-09-22 08:18 -0400
csiph-web