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 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
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
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
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.
--
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/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
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
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