Re: Want way to run background processes with SIGINT unignored

[Linda Walsh]

Chet Ramey wrote:
> On 10/10/15 4:19 PM, Linda Walsh wrote:
> > Chet Ramey wrote:
> > > On 10/9/15 2:42 PM, Ian Jackson wrote:
> > > > However, it would be very easy for bash to provide an option (via `set
> > > > -o' perhaps) to disable this behaviour.  That is, to allow SIGINT to
> > > > be delivered normally to child processes.
> > > I'm restricting non-standard options to `shopt' to avoid any possible
> > > conflict with future posix changes.
> > ---
> > Thats a straw-man excuse if I ever heard one: use a "bash_"
> > prefix to any new options.  But, still, if you think even that
> > that might collide w/future posix choices, then don't use shopt
> > at all: use "bashopt" with bash-defined options and usage.
> > Either way, that should allay your worries on that front.
>
> That's a fairly impressive misunderstanding.  I'm talking about adding
> options to `shopt', which is not standardized and specific to bash,
> instead of adding the `set -o' option Ian requested because I'm leaving
> the `set -o' namespace to Posix.
---
        Oh... that explains the itch in the back of my head as
I wrote that... but your wording could be taken either way if
one wasn't remembering shopt was already 'bash-only'.

        As far as it being an impressive misunderstanding, thanks, er,
I mean, I've done better!...er...yeah, yeah, yeah...


> > > > With such an option, scripts which run on modern systems and which
> > > > attempt to parallelise their work, would be able to arrange that ^C
> > > > properly cleans up the whole process group, rather than leaving the
> > > > background tasks running (doing needless work and perhaps causing
> > > > lossage).
> > ----
> >     I pointed this out as a serious regression in 4.3 as bash
> > makes steps to really screw up async/realtime children handling
> > work in:
>
> This really doesn't have anything to do with what Ian is talking about.
-----
	no?  they want to run background processes and not have 
the sig handlers mangled (and presumably that means getting the 
signals in real time -- not waiting for the users next keypress!)
Requiring timely delivery of said signals, would be required for
their use case of " a bash script which invokes a
number of subprocesses in parallel and collects the output. ".  If
the foreground process is also waiting for user input to provide
interactivity, will the SIGCHLD events come in when the children
terminate or when the foreground process leaves readline?


>