bug-bash
[Top][All Lists]
Advanced

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

Re: looking for consistent C-c trap behavior


From: Eduardo Bustamante
Subject: Re: looking for consistent C-c trap behavior
Date: Fri, 17 Apr 2020 13:17:39 -0700

On Fri, Apr 17, 2020 at 1:09 PM Greg Wooledge <address@hidden> wrote:
>
> On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote:
> > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for
> > the GNU Bourne Again SHell <address@hidden> wrote:
> > >
> > > I've noticed that if I trap SIGINT in a bash script, the behavior when 
> > > encountering C-c depends on whether an external command (eg. 'sleep 100') 
> > > or a builtin command (like 'read -p') was encountered.
> > >
> > > I attach an example script which requires me to press C-c twice to 
> > > interrupt the builtin 'read -p' command, and it only works because I'm 
> > > restoring the trap via 'trap - SIGINT' the first time.
> > >
> > > My goal is to have C-c interrupt and use that exit code (130 most likely) 
> > > to exit with from script, regardless or whether or not the interrupted 
> > > command in the script was an internal or external one.
> > >
> > > How to do?
> >
> > I recommend reading: https://www.cons.org/cracauer/sigint.html
> >
> > The problem is that the signal is sent to the foreground process. When
> > "sleep" is running, it's the sleep command that receives the signal
> > and decides what to do with it. Not bash.
>
> That's not quite right.  When you press ^C in a terminal, SIGINT is sent
> to *all* of the processes in the "foreground" process group -- both sleep
> and bash, in the case you're discussing.

Oops. Apologies for giving out incorrect information.

And thank you for taking your time to explain it properly.



reply via email to

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