Op 04-11-16 om 21:41 schreef Martijn Dekker:
> $ fn() { false && echo bug || echo ok; }
> $ fn
> ok
> $ fn
> ok
> $ fn | cat
> ok
> $ fn | cat
> bug
> $ fn | cat
> bug
> $ (fn) | cat
> ok
Another datapoint: the result and output is exactly as above even if you
use if/then/else.
fn() { if false; t
Normal bash:
$ kill -l 141
PIPE
Bash compiled with --enable-minimal-config --enable-alias:
$ kill -l 141
SIGPIPE
That SIG prefix shouldn't be there. (Enabling POSIX mode makes no
difference to the output.)
A look at the source tells me that, for some reason, the POSIXly correct
output of 'kill
My development with Modernish just exposed the following bug on bash
4.4.0(1)-maint, bash-20161028 snapshot, compiled with
--enable-minimal-config --enable-alias:
$ fn() { false && echo bug || echo ok; }
$ fn
ok
$ fn
ok
$ fn | cat
ok
$ fn | cat
bug
$ fn | cat
bug
$ (fn) | cat
ok
So apparently thi
On 11/4/16 2:02 AM, Eduardo A. Bustamante López wrote:
> Actually, there are more leaks in execute_cmd.c, I'm just going to list them
> here.
Same.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU
On 11/4/16 12:35 AM, Eduardo A. Bustamante López wrote:
> I ran the configure script with the following arguments:
>
> hp% ./configure CC=gcc-6 CFLAGS='-Wall -g -ggdb -O0 -fsanitize=address'
> LDFLAGS=-fsanitize=address --without-bash-malloc
>
> Which enables the LeakSanitizer
> (https://gi
On 11/4/16 6:36 AM, Clark Wang wrote:
> For example, in vi-insert mode I input following in the command line:
>
> # foo abc
>
> The cursor is right after 'c'. Now if I press ESC then it'll go to
> vi-command mode and the cursor will move to under 'c'. But if I press jj
> the cursor would be still
On 11/4/16 3:05 AM, Martijn Dekker wrote:
> Op 04-11-16 om 01:27 schreef Eduardo Bustamante:
>> I agree with everything, except calling it severe. This is
>> self-inflicted harm, and easy to work around
>
> It is not self-inflicted. The behaviour is a bug in bash. The user did
> nothing to cause t
On Fri, Nov 4, 2016 at 10:32 PM, Chet Ramey wrote:
> On 11/4/16 6:30 AM, Clark Wang wrote:
> > For example, if I have inputted the following after the prompt:
> >
> > # foo "abc"
> >
> > In bash 4.3's vi-insert mode, when I press ctrl-w it'll delete the whole
> > "abc" (including quotes). But wit
On Fri, Nov 04, 2016 at 10:32:17AM -0400, Chet Ramey wrote:
> On 11/4/16 6:30 AM, Clark Wang wrote:
> > For example, if I have inputted the following after the prompt:
> >
> > # foo "abc"
> >
> > In bash 4.3's vi-insert mode, when I press ctrl-w it'll delete the whole
> > "abc" (including quotes)
On 11/4/16 6:30 AM, Clark Wang wrote:
> For example, if I have inputted the following after the prompt:
>
> # foo "abc"
>
> In bash 4.3's vi-insert mode, when I press ctrl-w it'll delete the whole
> "abc" (including quotes). But with 4.4 I have to press ctrl-w for 3 times
> (one for the right " c
On 11/4/16 12:17 AM, Eduardo A. Bustamante López wrote:
> I'm running configure with the following flags:
>
> |./configure CC=gcc-6
>
> The error I get while building:
Thanks for the report. I'm not working on a system that uses the bash
malloc right now.
--
``The lyf so short, the craft
For example, in vi-insert mode I input following in the command line:
# foo abc
The cursor is right after 'c'. Now if I press ESC then it'll go to
vi-command mode and the cursor will move to under 'c'. But if I press jj
the cursor would be still after 'c' and if then I press h the cursor will
ski
(reproduced with bash 4.3 or 4.4 on Debian unstable and Ubuntu 16.04).
perl -le "printf q([[ $'\U%X' = $'\U%X' ]] || echo %06X: $'\U%X').\"\n\",
\$_,\$_,\$_,\$_ for (1..0xd7FF, 0xE000..0x10)" |
LC_ALL=zh_HK.big5hkscs bash | LC_ALL=C sed -n l
Where the perl command outputs:
[[ $'\U1' = $'
If you want to split with read, use a tempenv IFS:
dualbus@hp:~/local/src/gnu/bash$ bash -c 'IFS="?" read a b c <<<
"hello?world?xyz"; echo "$a"'
hello
If you want to split using word splitting:
dualbus@hp:~/local/src/gnu/bash$ bash -c 'v="hello?world?xyz";
IFS="?"; set -- $v; unset
Op 04-11-16 om 01:27 schreef Eduardo Bustamante:
> I agree with everything, except calling it severe. This is
> self-inflicted harm, and easy to work around
It is not self-inflicted. The behaviour is a bug in bash. The user did
nothing to cause that bug.
Even if you think it's somehow reasonable
15 matches
Mail list logo