bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGINT handling


From: Stephane Chazelas
Subject: Re: SIGINT handling
Date: Tue, 22 Sep 2015 13:47:23 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]