Re: Bug with && in piped functions in minimal-config bash

2016-11-04 Thread Martijn Dekker
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;

'kill -l' outputs SIG prefix if job control not compiled in

2016-11-04 Thread Martijn Dekker
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

Bug with && in piped functions in minimal-config bash

2016-11-04 Thread Martijn Dekker
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

Re: memory leak in execute_simple_command when dofork is true

2016-11-04 Thread Chet Ramey
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

Re: memory leak in execute_simple_command when dofork is true

2016-11-04 Thread Chet Ramey
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 >

Re: bind -m vi-insert '"jj": "\e"' problem in 4.4

2016-11-04 Thread Chet Ramey
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

Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]

2016-11-04 Thread Chet Ramey
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

Re: [Help-bash] How to make vi-insert mode's ctrl-w work in the 4.3 way?

2016-11-04 Thread Clark Wang
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"

Re: [Help-bash] How to make vi-insert mode's ctrl-w work in the 4.3 way?

2016-11-04 Thread Greg Wooledge
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

Re: [Help-bash] How to make vi-insert mode's ctrl-w work in the 4.3 way?

2016-11-04 Thread Chet Ramey
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 "

Re: devel branch fails to build when using bash malloc due to missing errno.h include

2016-11-04 Thread Chet Ramey
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

bind -m vi-insert '"jj": "\e"' problem in 4.4

2016-11-04 Thread Clark Wang
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

[bug] [[ $'\Ux' = $'\Ux' ]] returns false for some values of x in some locales

2016-11-04 Thread Stephane Chazelas
(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' =

Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]

2016-11-04 Thread Eduardo Bustamante
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

Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]

2016-11-04 Thread Martijn Dekker
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

Re: memory leak in execute_simple_command when dofork is true

2016-11-04 Thread Eduardo A . Bustamante López
Actually, there are more leaks in execute_cmd.c, I'm just going to list them here. --- hp% ./bash -c '(:)' =