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


Groups > gnu.bash.bug > #11535

Re: SIGINT handling

From Stephane Chazelas <stephane.chazelas@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: SIGINT handling
Date 2015-09-22 13:47 +0100
Message-ID <mailman.1587.1442926053.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


2015-09-22 08:18:08 -0400, Greg Wooledge:
[...]
> 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.

Hi Greg,

Yes, this whole thread is about the behaviour of uninteractive
bash with commands that call exit() upon SIGINT. It was
initially a follow-up on
https://unix.stackexchange.com/questions/230421/unable-to-stop-a-bash-script-with-ctrlc/230568#230568

which was about ping specifically.

It's true that with shells implementing WCE, the behaviour of
ping is unfortunate, but I don't think we can say that ping is
to blame, more WCE.

ping cannot exit other than on error or when killed. It seems
reasonable for it to exit (after printing the statistics)
if there was no error upon CTRL-C.

Note that the iputils version does a
        exit(!nreceived || (deadline && nreceived < npackets));

It it returning information to the caller which it couldn't do
if it killed itself.

That allows system("ping something") for instance to make use of
the return status (system(3) ignores SIGINT in the parent).

The WCE behaviour is cause for a number of bugs like that so I'm
not sure it's such a great idea.

-- 
Stephane

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


Thread

Re: SIGINT handling Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-09-22 13:47 +0100

csiph-web