Hi Chet,
Is there any news on this? I noticed that Bash-4.4 patch 11 do touches
something related to
signals, subshell and command substitution but I still get the same
behavior on 4.4.12(1)-release (x86_64-suse-linux-gnu)
I came up with a smaller script for this bug.
trap "sleep 2" USR1
x=$(kil
Hello,
Bash was supposed to return 128+signal if a signal is received while
running wait command.
However, the "builtin wait" does not do the same. "builtin wait" simply
ignores that the signal
happened.
This happens at least since version 3.2.57(2)-release
(x86_64-suse-linux-gnu) until 4.4.12(1)
On 5/2/17 10:22 AM, Eduardo Bustamante wrote:
The valgrind issue might be related to the false positive issue from a
couple of weeks ago, but it really doesn't matter. The bash malloc
severely confuses valgrind.
> I think this is the fix:
>
> dualbus@debian:~/src/gnu/bash$ git diff
> diff --git
On Tue, May 2, 2017 at 9:04 AM, Chet Ramey wrote:
[...]
dualbus@debian:~/src/gnu/bash$ valgrind --leak-check=full ./bash
==30183== Memcheck, a memory error detector
==30183== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30183== Using Valgrind-3.12.0.SVN and LibVEX; rerun with
On 5/2/17 1:22 AM, Eduardo Bustamante wrote:
> bind '\xx":""'
chet(1)$ valgrind ./bash
==8686== Memcheck, a memory error detector
==8686== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==8686== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==8686== Command: ./
On 5/2/17 12:41 AM, Eduardo Bustamante wrote:
> On Mon, Apr 24, 2017 at 3:48 PM, Chet Ramey wrote:
> [...]
>> That works on Linux, but not on the BSDs, since Posix says it doesn't
>> have to.
>
> I see that a test for this has been added to comsub.tests:
>
> dualbus@debian:~/src/gnu/bash$ git lo
On 5/2/17 9:07 AM, Eduardo Bustamante wrote:
> On Tue, May 2, 2017 at 7:13 AM, Greg Wooledge wrote:
> [...]
>> would be safe. Your test command has 6 arguments, for which "the results
>> are unspecified".
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
>
> Hm. That section
On Tue, May 2, 2017 at 7:13 AM, Greg Wooledge wrote:
[...]
> would be safe. Your test command has 6 arguments, for which "the results
> are unspecified".
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
Hm. That section of the standard refers to "The algorithm for
determinin
On Mon, May 01, 2017 at 11:24:44PM -0500, Eduardo Bustamante wrote:
> > For the behavior you want, you need something like:
> >
> > test ! -h "$pathname" -a -f "$pathname"
Don't use that.
test ! -h "$pathname" && test -f "$pathname"
would be safe. Your test command has 6 arguments, for which
