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


Groups > gnu.bash.bug > #11560

Re: SIGINT handling

From Stephane Chazelas <stephane.chazelas@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: SIGINT handling
Date 2015-09-24 20:49 +0100
Message-ID <mailman.1757.1443124155.19560.bug-bash@gnu.org> (permalink)
References (3 earlier) <56035164.30105@case.edu> <20150924060122.GA4338@chaz.gmail.com> <20150924062044.GA5756@chaz.gmail.com> <20150924135756.GA5007@chaz.gmail.com> <5604469C.4050406@case.edu>

Show all headers | View raw


2015-09-24 14:53:16 -0400, Chet Ramey:
> On 9/24/15 9:57 AM, Stephane Chazelas wrote:
> 
> > IMO, the best approach would be to give up on WCE altogether
> > which is more source of frustration anyway than it has ever
> > helped. I live very well with a /bin/sh (dash) and interactive
> > shell (zsh) that don't do it.
> 
> We'll agree to disagree.
[...]


Now that we're settled on WCE,

would you agree that

a=$(cmd-that-catches-sigint)

should behave like

(cmd-that-catches-sigint)

(as in, not exit the shell as per WCE)?

What about $PIPESTATUS?

In:

cmd-that-catches-sigint | cmd-that-does-not
or
cmd-that-does-not | cmd-that-catches-sigint

Should we exit on SIGINT or leave that command run in
background?

Should pipefail have an influence on the behaviour? What about
lastpipe?

What about when using the wait builtin?

Why should:

cmd & wait "$!"

be treated differently from

cmd

?

Because cmd's stdin is /dev/null and so is unlikely to be an
interactive command?

So we admit WCE is a kludge 

-- 
Stephane

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


Thread

Re: SIGINT handling Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-09-24 20:49 +0100

csiph-web