Re: SIGINT handling

2015-09-24 Thread Pádraig Brady
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

Re: SIGINT handling

2015-09-24 Thread Stephane Chazelas
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

Re: SIGINT handling

2015-09-24 Thread Stephane Chazelas
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

Re: SIGINT handling

2015-09-24 Thread Chet Ramey
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

Re: SIGINT handling

2015-09-24 Thread 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. --

Re: SIGINT handling

2015-09-24 Thread Stephane Chazelas
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

Re: SIGINT handling

2015-09-24 Thread Chet Ramey
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

[PATCH] input: fix logic bug that breaks on O_TEXT systems

2015-09-24 Thread Eric Blake
The bash-20101229 snapshot introduced an attempt to incorporate some patches that were previously used downstream by Cygwin with regards to managing scripts read with O_TEXT mode (where lseek() sees different offsets than the number of bytes read, because the system is converting physical '\r\n' in

Re: [PATCH] input: fix logic bug that breaks on O_TEXT systems

2015-09-24 Thread Chet Ramey
On 9/24/15 5:47 PM, Eric Blake wrote: > The bash-20101229 snapshot introduced an attempt to incorporate > some patches that were previously used downstream by Cygwin > with regards to managing scripts read with O_TEXT mode (where > lseek() sees different offsets than the number of bytes read, > bec