On 2/6/23 10:26 PM, Martin D Kealey wrote:
By orthogonal, I meant these things should ideally be managed by separate
controls:
1. ignoring signals (or not)
2. redirecting filedescriptors
3. immediately waiting on the process (or not)
4. creating new process groups
5. sending a signal t
On Fri, 3 Feb 2023 at 07:17, Chet Ramey wrote:
> On 1/28/23 5:56 AM, Martin D Kealey wrote:
> > Firstly, let's just leave aside "POSIX requires this" for a bit.
> Be that as it may, POSIX exists and this is a requirement. It's also how
> other shells behave.
>
Of course. I'm only contemplating m
On 1/28/23 5:56 AM, Martin D Kealey wrote:
Firstly, let's just leave aside "POSIX requires this" for a bit. I know
that the requirement is there, and I think it is one of those broken things
that ought to have been dropped from POSIX, or at least reduced to optional
rather than required.
Be
Firstly, let's just leave aside "POSIX requires this" for a bit. I know
that the requirement is there, and I think it is one of those broken things
that ought to have been dropped from POSIX, or at least reduced to optional
rather than required.
On Tue, 24 Jan 2023 at 07:35, Chet Ramey wrote:
>
On 1/21/23 7:55 AM, Tycho Kirchner wrote:
Am 16.01.23 um 18:26 schrieb Chet Ramey:
The fix is to add enough state machinery to detect this situation and
behave in a way that can satisfy both the standard and the later
interpretation, while being careful not to undo this work later. This is
ob
On Sat, Jan 21, 2023 at 01:55:27PM +0100, Tycho Kirchner wrote:
> cmd1 &
> cmd2 &
> wait
>
> If the user having launched this script from the interactive terminal aborts
> it by hitting Ctrl+C, by default, the shell sends SIGINT to the process group
> (pgid) of the script. However, while cmd1 an
Am 16.01.23 um 18:26 schrieb Chet Ramey:
The fix is to add enough state machinery to detect this situation and
behave in a way that can satisfy both the standard and the later
interpretation, while being careful not to undo this work later. This is
obviously not how bash worked in the past.
On 1/12/23 6:34 PM, Tycho Kirchner wrote:
Hi,
we found quite some inconsistency and weirdness in the handling of SIGINT's
during async function calls and were wondering, whether those are expected.
All calls were executed from a script with jobcontrol turned off (set +m)
while pressing Ctrl+C
Date:Fri, 13 Jan 2023 08:29:25 +0100
From:Tycho Kirchner
Message-ID: <6df2fd46-18e8-775d-a670-bd29ffdf3...@mail.de>
| However, did you actually actually put the short snippets into a script,
No, I didn't, and now I have, I see what you mean, bash does look to
be do
Am 13.01.23 um 03:02 schrieb Robert Elz:
Date:Fri, 13 Jan 2023 00:34:02 +0100
From:Tycho Kirchner
Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de>
| we found quite some inconsistency and weirdness
| in the handling of SIGINT's during async func
Oh, the differences in what trap -p is printing is because
of special case handling for trap in a subshell environment,
when the trap command is the first (maybe only) command
executed (details vary between shells). That is mostly
intended to allow T=$(trap -p) to work, but is usually applied
to a
Date:Fri, 13 Jan 2023 00:34:02 +0100
From:Tycho Kirchner
Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de>
| we found quite some inconsistency and weirdness
| in the handling of SIGINT's during async function calls
Not inconsistent or weird, and has noth
Hi,
we found quite some inconsistency and weirdness in the handling of SIGINT's
during async function calls and were wondering, whether those are expected. All
calls were executed from a script with jobcontrol turned off (set +m) while
pressing Ctrl+C shortly afterwards. In summary:
The main IN
On 9/21/15 5:07 PM, Stephane Chazelas wrote:
> The problem is that here the parent's SIGINT handler is run upon
> the return from waitpid(), just after. My patch doesn't rely on
> EINTR from waitpid() (which doesn't happen here, waitpid() returns
> with the pid of the child that did an exit() upon
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
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.
--
On 9/22/15 8:18 AM, Greg Wooledge wrote:
> On Mon, Sep 21, 2015 at 10:07:55PM +0100, Stephane Chazelas wrote:
>> Maybe the test scenario was not clear:
>>
>> bash -c 'cmd; echo hi'
>>
>> is run from an interactive shell, cmd is a long running
>> application (the problem that sparked this discussion
Given that the bug was introduced by Linus' patch (to fix a bug
that anyway is in all shell implementations that do WCE) and
that it's caused by a behaviour that seems to be specific to the
Linux kernel (that the kernel seems to be messing up with the
order of delivery of the SIGCHLD (or return fro
2015-09-24 09:36:08 +0100, Pádraig Brady:
[...]
> > (gdb) handle SIGINT nostop pass
[...]
>
> In case it's relevant, I'm not entirely sure of gdb's signal handling:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18364
Yes, I wondered about that.
I'd expect the "handle SIGINT nostop pass", to
On 24/09/15 07:20, Stephane Chazelas wrote:
> 2015-09-24 07:01:23 +0100, Stephane Chazelas:
>> 2015-09-23 21:27:00 -0400, Chet Ramey:
>>> On 9/19/15 5:31 PM, Stephane Chazelas wrote:
>>>
In case it was caused by some Debian patch, I recompiled the
code of 4.3.42 from gnu.org and the one f
2015-09-24 07:01:23 +0100, Stephane Chazelas:
> 2015-09-23 21:27:00 -0400, Chet Ramey:
> > On 9/19/15 5:31 PM, Stephane Chazelas wrote:
> >
> > > In case it was caused by some Debian patch, I recompiled the
> > > code of 4.3.42 from gnu.org and the one from the devel branch on
> > > the git reposi
2015-09-23 21:27:00 -0400, Chet Ramey:
> On 9/19/15 5:31 PM, Stephane Chazelas wrote:
>
> > In case it was caused by some Debian patch, I recompiled the
> > code of 4.3.42 from gnu.org and the one from the devel branch on
> > the git repository (commit bash-20150911 snapshot) and still:
> >
> > $
On 9/20/15 11:52 AM, Stephane Chazelas wrote:
> When the above code exits without printing "hi", we see this
> call stack for instance (breakpoint on kill() in gdb):
>
> #0 kill () at ../sysdeps/unix/syscall-template.S:81
> #1 0x0045dd8e in termsig_handler (sig=) at sig.c:588
> #2 0x00
On 9/19/15 5:31 PM, Stephane Chazelas wrote:
> In case it was caused by some Debian patch, I recompiled the
> code of 4.3.42 from gnu.org and the one from the devel branch on
> the git repository (commit bash-20150911 snapshot) and still:
>
> $ ./bash -c 'sh -c "trap exit INT; sleep 10; :"; echo
2015-09-22 12:04:45 -0600, Bob Proulx:
> Greg Wooledge wrote:
> > Just for the record, ping is the *classic* example of an incorrectly
> > written application that traps SIGINT but doesn't kill itself with
> > SIGINT afterward. (This seems to be true on multiple systems -- at
> > the very least, H
Greg Wooledge wrote:
> Just for the record, ping is the *classic* example of an incorrectly
> written application that traps SIGINT but doesn't kill itself with
> SIGINT afterward. (This seems to be true on multiple systems -- at
> the very least, HP-UX and Linux pings both suffer from it.)
The c
2015-09-22 15:18:32 +0100, Stephane Chazelas:
> 2015-09-22 09:41:35 -0400, Chet Ramey:
> [...]
> > > AFAICT emacs starts a new process group (and makes it the
> > > foreground process group).
> >
> > Maybe, if it's being run from an interactive shell or in a separate
> > X window. On the other ha
On 9/22/15 11:28 AM, Stephane Chazelas wrote:
> 2015-09-22 15:18:32 +0100, Stephane Chazelas:
>> 2015-09-22 09:41:35 -0400, Chet Ramey:
>> [...]
AFAICT emacs starts a new process group (and makes it the
foreground process group).
>>>
>>> Maybe, if it's being run from an interactive shell
2015-09-22 16:28:16 +0100, Stephane Chazelas:
[...]
> To add on that, the code was removed at some point altogether
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58eb6cf0f77547d29f4fddca922eb6f98c0ffb28
> in emacs-24.0.96 and then added back without the #ifdef
> BSD_PGRPS
> http://git.sav
2015-09-22 09:41:35 -0400, Chet Ramey:
[...]
> > AFAICT emacs starts a new process group (and makes it the
> > foreground process group).
>
> Maybe, if it's being run from an interactive shell or in a separate
> X window. On the other hand, run this script with `dash':
[...]
It does that uncondi
2015-09-22 09:41:35 -0400, Chet Ramey:
[...]
> > AFAICT emacs starts a new process group (and makes it the
> > foreground process group).
>
> Maybe, if it's being run from an interactive shell or in a separate
> X window. On the other hand, run this script with `dash':
>
> echo before
> emacs -n
On 9/21/15 5:24 PM, Stephane Chazelas wrote:
> 2015-09-21 15:34:28 -0400, Chet Ramey:
>> On 9/21/15 5:48 AM, Stephane Chazelas wrote:
>>
>>> I'm not sure I prefer that WCE approach over WUE. Wouldn't it be
>>> preferable that applications that intercept SIGINT/QUIT/TSTP for
>>> anything other than
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 wi
On Mon, Sep 21, 2015 at 10:07:55PM +0100, Stephane Chazelas wrote:
> Maybe the test scenario was not clear:
>
> bash -c 'cmd; echo hi'
>
> is run from an interactive shell, cmd is a long running
> application (the problem that sparked this discussion was with
> ping and I showed examples with an
2015-09-22 07:41:09 +0100, Stephane Chazelas:
[...]
> I wonder how FreeBSD sh addresses that.
>
> BTW, ksh93 has the problem (the 2011 one) as well as in:
>
> ksh93 -c 'while :; do /bin/true; done'
>
> Sometimes is not interrupted by the first ^C. (same with bash
> with my patch applied).
[...]
2015-09-21 22:07:55 +0100, Stephane Chazelas:
[...]
> Can you please clarify why the check for EINTR was needed?
>
> What do you suggest we do to fix that issue?
[...]
> The thing is that thread was about the opposite problem at the
> other end of the spectrum so we need to find the right way to d
2015-09-21 22:24:03 +0100, Stephane Chazelas:
[...]
> If it didn't, we could not use it in scripts of shells that
> don't do WCE *but also in non-shell scripts* (perl, python,
> ruby...) or non-scripts.
[...]
For completeness
perl's and python's system() like system(3) ignore SIGINT, so
it's a WU
2015-09-21 15:34:28 -0400, Chet Ramey:
> On 9/21/15 5:48 AM, Stephane Chazelas wrote:
>
> > I'm not sure I prefer that WCE approach over WUE. Wouldn't it be
> > preferable that applications that intercept SIGINT/QUIT/TSTP for
> > anything other than clean-up before exit/suspend implement job
> > c
2015-09-21 15:04:46 -0400, Chet Ramey:
> On 9/20/15 3:45 PM, Stephane Chazelas wrote:
> > 2015-09-20 17:12:45 +0100, Stephane Chazelas:
> > [...]
> >> I thought the termsig_handler was being invoked upon SIGINT as
> >> the SIGINT handler, but it is being called explicitely by
> >> set_job_status_an
On 9/21/15 5:48 AM, Stephane Chazelas wrote:
> I'm not sure I prefer that WCE approach over WUE. Wouldn't it be
> preferable that applications that intercept SIGINT/QUIT/TSTP for
> anything other than clean-up before exit/suspend implement job
> control themselves instead (like vi's :! should crea
On 9/20/15 3:45 PM, Stephane Chazelas wrote:
> 2015-09-20 17:12:45 +0100, Stephane Chazelas:
> [...]
>> I thought the termsig_handler was being invoked upon SIGINT as
>> the SIGINT handler, but it is being called explicitely by
>> set_job_status_and_cleanup so the problem is elsewhere.
>>
>> child_
On Mon, Sep 21, 2015 at 10:48:07AM +0100, Stephane Chazelas wrote:
> 2015-09-19 21:36:28 +0100, Stephane Chazelas:
> > 2015-09-18 16:14:39 +0100, Stephane Chazelas:
> > [...]
> > > In:
> > >
> > > bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> > >
> > > If I press Ctrl-C, I still see "hi
2015-09-21 17:35:36 +0200, Jilles Tjoelker:
[...]
> This kind of job control manipulation is very hard to get right in the
> general case. FreeBSD's su does it, and it needed various iterations to
> fix hanging processes or unexpected logouts, some of which only occur
> when the application is star
2015-09-21 17:35:36 +0200, Jilles Tjoelker:
[...]
> > One could also argue, that to be consistent, SIGTSTP and SIGQUIT
> > should be treated similarly (strangely enough
> > http://www.cons.org/cracauer/sigint.html doesn't mention SIGTSTP).
>
> Agreed for SIGQUIT, but not for SIGTSTP. For SIGTSTP,
2015-09-19 21:36:28 +0100, Stephane Chazelas:
> 2015-09-18 16:14:39 +0100, Stephane Chazelas:
> [...]
> > In:
> >
> > bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
> >
> > If I press Ctrl-C, I still see "hi".
> [...]
>
> Jilles provided with the explanation at
> http://unix.stackexchange
2015-09-20 17:12:45 +0100, Stephane Chazelas:
[...]
> I thought the termsig_handler was being invoked upon SIGINT as
> the SIGINT handler, but it is being called explicitely by
> set_job_status_and_cleanup so the problem is elsewhere.
>
> child_caught_sigint is 0 while if I understand correctly it
[...]
> When the above code exits without printing "hi", we see this
> call stack for instance (breakpoint on kill() in gdb):
>
> #0 kill () at ../sysdeps/unix/syscall-template.S:81
> #1 0x0045dd8e in termsig_handler (sig=) at sig.c:588
> #2 0x0045ddef in termsig_handler (sig=)
2015-09-19 21:28:24 -0400, Chet Ramey:
> On 9/19/15 5:31 PM, Stephane Chazelas wrote:
> > 2015-09-19 16:42:28 -0400, Chet Ramey:
> > [...]
> >> I'm surprised you've managed to avoid the dozen or so discussions on the
> >> topic.
> >>
> >> http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00108.
On 9/19/15 5:31 PM, Stephane Chazelas wrote:
> 2015-09-19 16:42:28 -0400, Chet Ramey:
> [...]
>> I'm surprised you've managed to avoid the dozen or so discussions on the
>> topic.
>>
>> http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00108.html
> [...]
>
> Thanks for the links. I still think
2015-09-19 16:42:28 -0400, Chet Ramey:
[...]
> I'm surprised you've managed to avoid the dozen or so discussions on the
> topic.
>
> http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00108.html
[...]
Thanks for the links. I still think the comments on the second
article I sent
(http://thread.
On 9/18/15 11:14 AM, Stephane Chazelas wrote:
> Hello.
>
> In:
>
> bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
>
> If I press Ctrl-C, I still see "hi".
>
> On Solaris with 4.1.11(2)-release (i386-pc-solaris2.11), that
> seems to be consistent.
>
> On Debian with 4.3.42(1)-release (x8
2015-09-18 16:14:39 +0100, Stephane Chazelas:
[...]
> In:
>
> bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
>
> If I press Ctrl-C, I still see "hi".
[...]
Jilles provided with the explanation at
http://unix.stackexchange.com/a/230731
with a link to:
http://www.cons.org/cracauer/sigint.h
Hello.
In:
bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi'
If I press Ctrl-C, I still see "hi".
On Solaris with 4.1.11(2)-release (i386-pc-solaris2.11), that
seems to be consistent.
On Debian with 4.3.42(1)-release (x86_64-pc-linux-gnu), that
seems to happen only in something like 80% of
53 matches
Mail list logo
