Re: Any chance of multi-dimensional arrays?

[Eduardo Bustamante]

Hey, calm down. People are just trying to help.

Also, this question has already been asked previously. Please read this:

http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00062.html

(To put you in context, Chet Ramey is the current maintainer of bash).

It's not really an important feature. Bash is already doing too much for a
*shell* language (yes, note that a shell language isn't the same as a
scripting language).

There are a lot of general purpose languages (not shell languages), that
support multi-dimensional arrays. And these languages can call external
tools just fine. Python, Perl, Ruby, ... pick one. Even Awk has faked
support for multi-dimensional arrays.

Don't take me wrong though. Bash is really good, for what it was meant. If
you need complex data structures, or complex text processing, bash isn't
really the best tool for the job.

Just do yourself a favor, and start learning a new language. One that
supports custom data structures. That already has support for
multi-dimensional arrays.


P.S.: If you still have problems understanding the difference between a
shell, and a general purpose language:
http://en.wikipedia.org/wiki/Shell_(computing)#Text_.28CLI.29_shells

--
Eduardo Bustamante





On Sun, Nov 25, 2012 at 9:32 PM, Rene Herman rene.her...@gmail.com wrote:

 On 11/25/2012 08:54 PM, Bob Proulx wrote:

  There are various naming conventions and schemes to simulate
 multi-dimensional arrays using single dimension arrays.  Since you
 want to continue with the shell and the shell has not (yet) provided
 multi-dimensional arrays then the only option for you is to simulate
 them. That isn't too difficult and if you search the web there are
 many different implementations with the biggest difference being
 whether ordering matters or not.


 Yes. However, that was not my question, as was also the case for the
 previous reply. I already indicated in the original posting that I'm aware
 of work-arounds. Here it is again:

 http://lists.gnu.org/archive/**html/bug-bash/2012-11/**msg00048.htmlhttp://lists.gnu.org/archive/html/bug-bash/2012-11/msg00048.html

 The question, to the bash developers (-- !) is simply if there are any
 plans for implementing multi-dimensional array support, with the two
 implied statements being that a) I'd like that and b) I have a fairly
 non-contrived use-case for them, which I thought might be welcome as an
 argument.

 It's been a long time since I participated on open-source mailing-lists
 and I'm remembering why. Please don't take it the wrong way, but please,
 pretty please, unless you can answer the question, just don't bother
 replying.

 Rene.

Re: bash doesn't display tabs for tabs -- ignores tabstops.

[Eduardo Bustamante]

The cool thing about free software is that you're free to submit
patches. Please consider that option, instead of ranting on what Chet
should do.

-- 
Eduardo A. Bustamante López

Re: How to read fields into an array?

[Eduardo Bustamante]

Remember to use help-bash for these questions.

Re: Regression with declare -i and arrays

[Eduardo Bustamante]

Nevermind. The patch is wrong, but at least it shows where the problem is
(if needs braces, around line 529)
El abr 3, 2015 8:48 PM, Eduardo A. Bustamante López dual...@gmail.com
escribió:

 Here's a patch:


 diff --git a/builtins/declare.def b/builtins/declare.def
 index 5ed83a0..f0f9a6d 100644
 --- a/builtins/declare.def
 +++ b/builtins/declare.def
 @@ -280,7 +280,7 @@ declare_internal (list, local_var)
return (sh_chkwrite (any_failed ? EXECUTION_FAILURE :
 EXECUTION_SUCCESS));
  }

 -#define NEXT_VARIABLE() free (name); list = list-next; continue
 +#define NEXT_VARIABLE() do { free (name); list = list-next; continue; }
 while(0)

/* There are arguments left, so we are making variables. */
while (list) /* declare [-aAfFirx] name [name ...] */

 --
 Eduardo Bustamante
 https://dualbus.me/

Re: Curious case statement error

[Eduardo Bustamante]

Character ranges are locale-dependant. Check the values of LC_ALL and
LC_COLLATE. Under some locales, the [A-Z] range is actually AaBb..Z. That's
why it's better to use the character classes, i.e. [[:alpha:]],
[[:lower:]], [[:upper:]], etc.

Unless you set the globasciiranges shopt:

  globasciiranges
If set, range expressions used in pattern matching bracket expressions (see
Pattern Matching) behave as if in the traditional C locale when performing
comparisons. That is, the current locale’s collating sequence is not taken
into account, so ‘b’ will not collate between ‘A’ and ‘B’, and upper-case
and lower-case ASCII characters will collate together.

Anyways, bash behavior here is correct. If you need some specific collation
order make sure to set your LC_* variables correctly, or use the POSIX
locale (LC_ALL=C)

Re: Patch for autoload.v3 to allow export of function

[Eduardo Bustamante]

On Wed, Feb 8, 2017 at 11:27 AM, Matthew Persico
 wrote:
[...]
>
> Where should it be discussed and how does one format and submit a patch
> (fork, clone, pull request or patch submission on the savanah site or
> something else)?

Hi Matthew, you can send patches to this list, or to Chet Ramey. You
can see the archives (https://lists.gnu.org/archive/html/bug-bash/)
for example on how people submit patches, but it's basically just
email the patch.

Re: echo -n

[Eduardo Bustamante]

El jue., feb. 2, 2017 9:00 AM, Sangamesh Mallayya <
sangamesh.sw...@in.ibm.com> escribió:

> [...]
>
> Please let us know if this a bug or do we have any other option to print
> -n ?
>

Use the printf builtin command. What you encountered is a known limitation
of the echo command, as specified by POSIX.

Re: Follow-up to Non-expanding here-documents inside command substitution

[Eduardo Bustamante]

On Thu, Feb 23, 2017 at 11:14 PM, Kevin Grigorenko
 wrote:
> On February 11th 2017, there was a discussion on the topic of "Non-expanding
> here-documents inside command substitution are subject to newline joining"
> where it was confirmed that Bash contains a bug. Two questions:
>
> 1. Is there a plan to fix this or should a patch be submitted?

The fix is already in the "devel" branch:
http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=ac495185aab17ef6030a02ddc0be33380a27a94d

Re: readonly changes set -e behavior

[Eduardo Bustamante]

On Tue, Feb 21, 2017 at 11:02 AM, Dennis Kuhn  wrote:
[...]
>
> When the variable s is set to readonly the script does not exit and echoes 
> "abc":
>
> #!/bin/bash
> set -e
>
> readonly s=$(false)
> echo "abc"
[...]

This is a commonly reported issue. The moment you add the readonly
builtin, you're no longer seeing the exit code from the command
substitution, but the exit code from readonly. See:

https://lists.gnu.org/archive/html/bug-bash/2012-10/msg00075.html
Command substitution and errexit
http://lists.gnu.org/archive/html/bug-bash/2014-08/msg00036.html
'declare' does not honor '-e' in command substituted assignments - a
bug
http://lists.gnu.org/archive/html/bug-bash/2015-09/msg00109.html local
keyword hides return code of command substitution

One easy way to workaround this is to do:

s=$(...); readonly s

Re: Bash bug

[Eduardo Bustamante]

You can do:

local var; var=$(...); ... $?

No need to make the declaration and assignment at the same time.

Re: Forcing builtins (interactive, non-interactive shells) to execute in fork()'ed process.

[Eduardo Bustamante]

Hi Matthew,

I have a couple questions:

1. How are you testing this? (small concrete cases are helpful)
2. Do you have some specific builtins that exhibit that behavior? (it
doesn't make sense for builtins to fork on their own, unless you're
doing an explicit subshell. Like you mentioned, executing cd in a
child process is moot
3. Can you send straces that show these forks?

I cannot reproduce this behavior:

dualbus@debian-512mb-sfo1-01:~$ PS1= strace -fe clone,execve,chdir
bash -c 'builtin echo $BASH_VERSION; cd /; /bin/echo'
execve("/bin/bash", ["bash", "-c", "builtin echo $BASH_VERSION; cd
/"...], [/* 16 vars */]) = 0
4.3.30(1)-release
chdir("/")  = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fa6dbec69d0) = 1490
Process 1490 attached
[pid  1490] execve("/bin/echo", ["/bin/echo"], [/* 16 vars */]) = 0

[pid  1490] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1490,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

dualbus@debian-512mb-sfo1-01:~$ strace -fe clone,execve,chdir bash -c
'builtin echo $BASH_VERSION; cd /; /bin/echo'
execve("/bin/bash", ["bash", "-c", "builtin echo $BASH_VERSION; cd
/"...], [/* 15 vars */]) = 0
4.3.30(1)-release
chdir("/")  = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f0405bf29d0) = 1497
Process 1497 attached
[pid  1497] execve("/bin/echo", ["/bin/echo"], [/* 16 vars */]) = 0

[pid  1497] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1497,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

dualbus@yaqui:~$ strace -fe clone,execve,chdir bash -c 'builtin echo
$BASH_VERSION; cd /; /bin/echo'
execve("/bin/bash", ["bash", "-c", "builtin echo $BASH_VERSION; cd
/"...], [/* 26 vars */]) = 0
4.3.46(1)-release
chdir("/")  = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f87132ba9d0) = 3661
strace: Process 3661 attached
[pid  3661] execve("/bin/echo", ["/bin/echo"], [/* 26 vars */]) = 0

[pid  3661] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3661,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

[dual...@ma.sdf.org ~]$ strace -fe clone,execve,chdir bash -c 'builtin
echo $BASH_VERSION; cd /; /bin/echo'
execve("/bin/bash", ["bash", "-c", "builtin echo $BASH_VERSION; cd
/"...], [/* 42 vars */]) = 0
4.1.2(1)-release
chdir("/")  = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f9e205989d0) = 29707
Process 29707 attached
[pid 29707] execve("/bin/echo", ["/bin/echo"], [/* 43 vars */]) = 0

[pid 29707] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29707,
si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++


There are definitely some optimization strategies bash uses under some
cases were it avoids forking (but this applies to external commands),
like this case:

dualbus@yaqui:~$ strace -fe clone,execve,chdir bash -c '/bin/echo $BASH_VERSION'
execve("/bin/bash", ["bash", "-c", "/bin/echo $BASH_VERSION"], [/* 26
vars */]) = 0
execve("/bin/echo", ["/bin/echo", "4.3.46(1)-release"], [/* 25 vars */]) = 0
4.3.46(1)-release
+++ exited with 0 +++

Since it's a single command in the -c ..., which means that it's safe
for bash to do exec to replace the current process with the external
command.

Re: Why does bash use xmalloc?

[Eduardo Bustamante]

Hi Peng. Read the link you provided again. xmalloc is not an
alternative version of malloc. It's just a common wrapper function
around malloc. You can go and see for yourself, the definition is
here: http://git.savannah.gnu.org/cgit/bash.git/tree/xmalloc.c#n97

If you want the rest of the commands execute properly, then make sure
that there's enough memory in the system, and remove artificial
restrictions (ulimit -v?). There's no trick here, and certainly no bug
in bash.

Re: How bash do tokenization?

[Eduardo Bustamante]

Check parser.y

Re: How bash do tokenization?

[Eduardo Bustamante]

On Tue, Oct 18, 2016 at 10:18 PM, Eduardo Bustamante <dual...@gmail.com> wrote:
> Check parser.y
Sorry, I meant parse.y, inside it you will find read_token and yylex.

Re: Race in bash-4.3 'typeset'?

[Eduardo Bustamante]

What version of bash are you using Stuart? typeset -p should work for
local variables too in any recent bash version.

Re: Race in bash-4.3 'typeset'?

[Eduardo Bustamante]

Ah! You're right. The second issue was already reported back in 2015
https://lists.gnu.org/archive/html/bug-bash/2015-02/msg00060.html

Now, regarding the SIGPIPE issue. The message bash is printing just
means that grep closed the pipe, so the bash process receives a
SIGPIPE when attempting to write. The output of strace (make sure you
use -f to follow forks) will make things easier to find out where the
issue is.

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

[Eduardo Bustamante]

what's wrong with?:

echo ${#array[@]}

It will return:

- With array=(1 2 3) -> 3
- With array=() -> 0
- With unset array -> 0
- With declare -a array -> 0

Seems to do what you're looking for.

Re: Could bash do what make does?

[Eduardo Bustamante]

Why should bash do what make already does?

Re: here-documents in $(command) substitution

[Eduardo Bustamante]

Hi Alexey,

Please read the specification of here-documents in the standard:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04

Quoting the relevant parts:

The here-document shall be treated as a single word that begins
after the next  and continues until there is a line
containing only the delimiter and a , with no 
characters in between. Then the next here-document starts, if there is
one. [...]

[n]<

Re: Not operator (~) fail on arithmetic expansion.

[Eduardo Bustamante]

Except that this is *inside* arithmetic context. Bash is definitely
doing something wrong here:

dualbus@hp:~$ for sh in bash zsh ksh93 mksh dash posh; do $sh -c 'echo
$0 $((~0))' $sh; done
bash: /home/dualbus: syntax error: operand expected (error token is
"/home/dualbus")
zsh -1
ksh93 -1
mksh -1
dash -1
posh -1

Re: Curious... on readline history patch -- round up memory allocs?

[Eduardo Bustamante]

I think this is unnecessary, malloc (either the bash malloc in
lib/malloc/malloc.c or the libc provided malloc) should already take
care of requesting memory in page sized chunks.

At least that's what I see here (morecore function):
http://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c?h=devel=216e2e9b8ba21fff677cf7794ef3d9af8c91d46d#n622

Unless I'm missing something, there's nothing to gain from optimizing
on top of xmalloc/malloc.

Re: Curious... on readline history patch -- round up memory allocs?

[Eduardo Bustamante]

The change was in reference to this bug report:
http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00107.html

The problem was that bash tried to allocate memory from the start
based on the value of HISTSIZE, but this proved problematic for users
which used a large HISTSIZE to have unlimited history.

The commit is here
http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=61c476d20d32dfd389c79fd4f2161a780685e42e

And the entry in the changelog:

+lib/readine/history.c
+ - add_history: if allocating the history list for the first time,
+ make sure the max history list size isn't so large that it will
+ cause allocation errors. Cap it at MAX_HISTORY_INITIAL_SIZE
+ (8192). Reported by Sean Zha 

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

[Eduardo Bustamante]

I agree with everything, except calling it severe. This is
self-inflicted harm, and easy to work around

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

[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 IFS; echo "$1"'
hello

If you want to use the $* parameter:

  dualbus@hp:~/local/src/gnu/bash$ bash -c 'set -- abc def ghi;
IFS="?"; echo "$*"; unset IFS'
  abc?def?ghi

I didn't say there's no bug. There is. And when I said,
"self-inflicted harm", I meant that leaving as IFS='][?*' is not
really needed. If you need to do some word splitting, set the IFS, and
then restore its original value or unset it.

Perhaps I'm missing something here, but I think for the relevant use
cases of IFS, there are sane work arounds.

What other use case would require of setting IFS to such value permanently?

Re: Change in behavior

[Eduardo Bustamante]

On Tue, Dec 13, 2016 at 9:08 AM, Vladimir Marek
 wrote:
[...]
> $ cat configure
> set -o posix
> echo ${0.8}
> echo after
>
> $ bash a.sh
> 3.2.52(1)-release
> a.sh: line 3: ${0.8}: bad substitution
> after
Is `a.sh' a copy of `configure'?

Re: Could bash do what make does?

[Eduardo Bustamante]

"build market"? What are you talking about? make was created with the
sole purpose of build automation. The shell was created to provide a
"human interface" to computer operators. These are very specific and
different purposes. Are you going to start asking next to re-implement
vi inside bash? to re-implement a mail user agent? a C compiler? Where
do you draw the line? Read:
http://www.catb.org/jargon/html/C/creeping-featurism.html

I doubt anyone is willing to go through the effort to re-implement all
the features that make provides, just because one guy thinks "it's
obsolete" -- it's not, by the way. make is very alive. Also, it is
part of the POSIX international standard. so any operating system that
claims to be compatible with UNIX must provide it, see [1] and [2] and
[3].

Also remember that nothing makes a stronger argument than patches. If
you want to see this feature implemented, I suggest that you start
looking into the features make provides, and send patches to add said
functionality to bash.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
[2] https://www.gnu.org/software/make/
[3] http://lists.gnu.org/archive/html/bug-make/

Re: [Help-bash] Bash Trap: How to Get Line Number of a Subprocess with Non-Zero Status

[Eduardo Bustamante]

On Thu, Dec 29, 2016 at 9:39 PM, Eduardo Bustamante <dual...@gmail.com> wrote:
> I'm adding the bug-bash list, since I think this is actually a bug in
> the parse_comsub function, or maybe in execute_command_internal. I
> haven't been able to figure it out yet. What I do know is that these
> two should behave the same:
I'm not sure what was I thinking, but these are of course very
different things (comsub and subshell) :-)

I still think this is a bug, because line number information
(line_number, line_number_for_err_trap and the line attribute in the
different command structures) is handled inconsistently.

The problem is that line information is lost when executing the body
of a function, so what bash does is to store line number information
in the command structures, so that it's able to correctly report to
the ERR trap when it is triggered. But for some reason this is not
handled in a consistent manner for different types of commands, so the
following fail:

- subshells e.g. (exit 17)
- arithmetic commands e.g. (( 0 ))
- conditional commands, e.g. [[ a = b ]]

I don't think this applies for the following types: if, case, for,
arith-for, but I may be wrong.

The attached err_lineno patch is a proposed fix. The reported line
number will be the closing line in the case of a subshell and the
other multi-line constructs. This seems to match the current behavior
when executing outside a function.
diff --git a/command.h b/command.h
index 3bf479a..678df79 100644
--- a/command.h
+++ b/command.h
@@ -353,6 +353,7 @@ typedef struct group_com {
 
 typedef struct subshell_com {
   int flags;
+  int line;
   COMMAND *command;
 } SUBSHELL_COM;
 
diff --git a/copy_cmd.c b/copy_cmd.c
index 826e0c3..ec71b70 100644
--- a/copy_cmd.c
+++ b/copy_cmd.c
@@ -221,6 +221,7 @@ copy_subshell_command (com)
   new_subshell = (SUBSHELL_COM *)xmalloc (sizeof (SUBSHELL_COM));
   new_subshell->command = copy_command (com->command);
   new_subshell->flags = com->flags;
+  new_subshell->line= com->line;
   return (new_subshell);
 }
 
diff --git a/execute_cmd.c b/execute_cmd.c
index 2fff093..29c3e2f 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -606,7 +606,7 @@ execute_command_internal (command, asynchronous, pipe_in, pipe_out,
 
   /* Fork a subshell, turn off the subshell bit, turn off job
 	 control and call execute_command () on the command again. */
-  line_number_for_err_trap = line_number;	/* XXX - save value? */
+  line_number_for_err_trap = line_number = command->value.Subshell->line;
   tcmd = make_command_string (command);
   paren_pid = make_child (p = savestring (tcmd), asynchronous);
 
@@ -3600,7 +3600,7 @@ execute_arith_command (arith_command)
 
   save_line_number = line_number;
   this_command_name = "((";	/* )) */
-  line_number = arith_command->line;
+  line_number_for_err_trap = line_number = arith_command->line;
   /* If we're in a function, update the line number information. */
   if (variable_context && interactive_shell)
 {
@@ -3801,7 +3801,7 @@ execute_cond_command (cond_command)
   save_line_number = line_number;
 
   this_command_name = "[[";
-  line_number = cond_command->line;
+  line_number_for_err_trap = line_number = cond_command->line;
   /* If we're in a function, update the line number information. */
   if (variable_context && interactive_shell)
 {
diff --git a/make_cmd.c b/make_cmd.c
index b42e9ff..6067ecb 100644
--- a/make_cmd.c
+++ b/make_cmd.c
@@ -822,6 +822,7 @@ make_subshell_command (command)
   temp = (SUBSHELL_COM *)xmalloc (sizeof (SUBSHELL_COM));
   temp->command = command;
   temp->flags = CMD_WANT_SUBSHELL;
+  temp->line = line_number;
   return (make_command (cm_subshell, (SIMPLE_COM *)temp));
 }
 

Re: [Help-bash] Bash Trap: How to Get Line Number of a Subprocess with Non-Zero Status

[Eduardo Bustamante]

On Thu, Dec 29, 2016 at 11:20 AM, Steve Amerige  wrote:
> I've posted a question to StackOverflow, but I'm hoping the experts here can
> chime in.
>
> http://stackoverflow.com/questions/41346907/bash-trap-how-to-get-line-number-of-a-subprocess-with-non-zero-status
>
> In essence, I want to know how to get the line number in a function of a
> subprocess that exits with a non-zero status (see line 20 below):
[...]
> Thanks,
> Steve Amerige

First: Try to do better formatting on your emails next time. The code
block is completely unreadable. I had to follow the stackoverflow link
to understand what you were asking.


I'm adding the bug-bash list, since I think this is actually a bug in
the parse_comsub function, or maybe in execute_command_internal. I
haven't been able to figure it out yet. What I do know is that these
two should behave the same:

dualbus@yaqui:~$ cat -n h
 1  #!/bin/bash
 2  shopt -s extdebug
 3  main() {
 4  trap 'echo $LINENO' ERR
 5  (exit 17)
 6  }
 7  main
dualbus@yaqui:~$ ./h
3

--- vs ---

dualbus@yaqui:~$ cat -n i
 1  #!/bin/bash
 2  shopt -s extdebug
 3  main() {
 4  trap 'echo $LINENO' ERR
 5  `exit 17`
 6  }
 7  main
dualbus@yaqui:~$ ./i
5

There's no actual reason for these two to be different, and this leads
me to think the behavior you're seeing is a bug somewhere in the
$(...) style command substitution parsing. Perhaps it misses updating
the line_number variable.

Re: ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances

[Eduardo Bustamante]

Please read http://mywiki.wooledge.org/DotFiles#Remote_shell_logins
(perhaps read http://mywiki.wooledge.org/DotFiles#Console_logins
first). The key to understanding this is to know that there are three
basic types of shell startup:

- Login shell
- Interactive shell
- Non-login Non-interactive shell (scripts and -c)

Each of these startup modes source different files. You need to make
sure you layout your initialization files with that in mind.

Re: Bug report: Bash version 4.3.11: complete: -i: invalid option on TAB auto completion

[Eduardo Bustamante]

I cannot reproduce this on bash 4.4:

dualbus@yaqui:~$ { for i in '-i' '\t' '\t' '\t' '\n' 'exit\n'; do
sleep 1; printf -- "$i"; done } | script --command 'bash --norc
--noprofile'
Script started, file is typescript
bash-4.4$ -i
bash: -i: command not found
bash-4.4$ exit
exit
Script done, file is typescript
dualbus@yaqui:~$ bash --version
GNU bash, version 4.4.0(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later


This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Do you have the bash-completion package installed? It sounds like the
bug is in that package, which is external to the GNU bash project
(https://github.com/scop/bash-completion)

Re: q// / qq// syntax or built-ins please ?

[Eduardo Bustamante]

Remember that bash's grammar is derived from the specification of the
POSIX shell 
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html).
Also, any addition to the bash grammar should be backwards compatible
(or enabled with a shopt, disabled by default), to avoid breaking
already working scripts.

Due to the complexity of the above limitations, I'd just use perl or
another language. It's not worth the effort. So don't feel discouraged
if you send patches and these are rejected.

[PATCH] Fix types in complete.c

[Eduardo Bustamante]

---
 lib/readline/complete.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/readline/complete.c b/lib/readline/complete.c
index 13241d13..726d51fb 100644
--- a/lib/readline/complete.c
+++ b/lib/readline/complete.c
@@ -2644,7 +2644,7 @@ rl_filename_completion_function (const char
*text, int state)
hit the end of the match list, we restore the original unmatched text,
ring the bell, and reset the counter to zero. */
 int
-rl_old_menu_complete (int count, invoking_key)
+rl_old_menu_complete (int count, int invoking_key)
 {
   rl_compentry_func_t *our_func;
   int matching_filenames, found_quote;
@@ -2947,7 +2947,7 @@ rl_menu_complete (int count, int ignore)
 }

 int
-rl_backward_menu_complete (int count, key)
+rl_backward_menu_complete (int count, int key)
 {
   /* Positive arguments to backward-menu-complete translate into negative
  arguments for menu-complete, and vice versa. */
-- 
2.11.0

Re: lockup in bgp_delete()

[Eduardo Bustamante]

This was reported a month ago:
http://lists.gnu.org/archive/html/bug-bash/2017-02/msg00025.html

Re: echo x > a > b > c > d

[Eduardo Bustamante]

On Sun, Apr 16, 2017 at 6:42 PM, 積丹尼 Dan Jacobson  wrote:
> Maybe bash should catch this
> $ echo x > a > b > c > d
> and print a warning.
> Same with
> $ cat < a < b < c < d

Why? These are perfectly valid grammatical constructs. What kind of
warning are you expecting to see and why?

Re: echo x > a > b > c > d

[Eduardo Bustamante]

On Sun, Apr 16, 2017 at 7:40 PM, 積丹尼 Dan Jacobson  wrote:
> OK sorry. I guess they make a lot of sense.

These constructs are valid grammatically, and have a well defined
semantic meaning. See:

dualbus@debian:~$ strace -e open bash -c ': &1|tail -n5
open("a", O_RDONLY) = 3
open("b", O_RDONLY) = 3
open("c", O_RDONLY) = 3
open("d", O_RDONLY) = 3
+++ exited with 0 +++

dualbus@debian:~$ strace -e open bash -c ': >a >b >c >d' 2>&1|tail -n5
open("a", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
open("b", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
open("c", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
open("d", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
+++ exited with 0 +++

Yes, it might be an awkward thing to write in a script, but it's still
valid. If you want recommendations on bad shell scripting practices,
perhaps you might want to try shellcheck instead?

Re: Issus with popd and pushd

[Eduardo Bustamante]

On Mon, Apr 17, 2017 at 4:57 PM, Pete Smith  wrote:
[...]
> So what's the possibility of adding -v option to popd and pushd???

Feel free to send patches. Under the hood, the pushd/popd builtins
call the dirs builtin with no arguments after their execution, so it's
just a matter of adding to pushd/popd the ability to interpret the -v
flag, and then pass this flag back to the dirs_builtin execution. In
the below patch I just pass the flag unconditionally, but it should
give you an idea of what you need to do.

# patched
bash-4.4$ pwd
/home/dualbus/foo/bar/baz
bash-4.4$ pushd a/
 0  ~/foo/bar/baz/a
 1  ~/foo/bar/baz
bash-4.4$ pushd bb/
 0  ~/foo/bar/baz/a/bb
 1  ~/foo/bar/baz/a
 2  ~/foo/bar/baz
bash-4.4$ popd
 0  ~/foo/bar/baz/a
 1  ~/foo/bar/baz

Or now that I think about it, you can get away with these functions:

# masked builtins
dualbus@debian:~/foo/bar/baz$ pushd() { builtin pushd "$@" >/dev/null;
dirs -v; }; popd(){ builtin popd "$@" >/dev/null; dirs -v; }
dualbus@debian:~/foo/bar/baz$ pushd a/
 0  ~/foo/bar/baz/a
 1  ~/foo/bar/baz
dualbus@debian:~/foo/bar/baz/a$ pushd bb/
 0  ~/foo/bar/baz/a/bb
 1  ~/foo/bar/baz/a
 2  ~/foo/bar/baz


# patch
dualbus@debian:~/src/gnu/bash$ PAGER= git diff -- builtins
diff --git a/builtins/pushd.def b/builtins/pushd.def
index 6579e4c8..bd41fcca 100644
--- a/builtins/pushd.def
+++ b/builtins/pushd.def
@@ -178,6 +178,8 @@ pushd_builtin (list)
   int j, flags, skipopt;
   intmax_t num;
   char direction;
+  WORD_DESC *wd;
+  WORD_LIST *wl;

   orig_list = list;

@@ -300,7 +302,11 @@ pushd_builtin (list)
   if (j == EXECUTION_SUCCESS)
 {
   add_dirstack_element ((flags & NOCD) ? savestring
(list->word->word) : current_directory);
-  dirs_builtin ((WORD_LIST *)NULL);
+
+  wd = make_word ("-v");
+  wl = make_word_list (wd, NULL);
+
+  dirs_builtin (wl);
   if (flags & NOCD)
free (current_directory);
   return (EXECUTION_SUCCESS);
@@ -324,6 +330,8 @@ popd_builtin (list)
   int flags;
   char direction;
   char *which_word;
+  WORD_DESC *wd;
+  WORD_LIST *wl;

   CHECK_HELPOPT (list);

@@ -400,7 +408,10 @@ popd_builtin (list)
pushd_directory_list[i] = pushd_directory_list[i + 1];
 }

-  dirs_builtin ((WORD_LIST *)NULL);
+  wd = make_word ("-v");
+  wl = make_word_list (wd, NULL);
+
+  dirs_builtin (wl);
   return (EXECUTION_SUCCESS);
 }

Re: Segfault when unsetting READLINE_LINE inside 'bind -x'

[Eduardo Bustamante]

On Sun, Apr 23, 2017 at 12:56 AM, Jaren Stangret  wrote:
> Hello,
>
> Instead of segfaulting, BASH should ensure READELINE_LINE is unset or set
> and empty.

I am able to reproduce this with the latest devel branch. Here's the
stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x76e827cc in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.3
(gdb) bt
#0  0x76e827cc in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.3
#1  0x556c88bb in maybe_make_readline_line (new_line=0x0) at
bashline.c:2548
#2  0x556cec8a in bash_execute_unix_command (count=1, key=13)
at bashline.c:4142
#3  0x5574e9f9 in _rl_dispatch_subseq (key=13,
map=0x55a56c80 , got_subseq=0) at
readline.c:851
#4  0x5574e5d4 in _rl_dispatch (key=0, map=0x55a56c80
) at readline.c:797
#5  0x5574de13 in readline_internal_char () at readline.c:629
#6  0x5574dea5 in readline_internal_charloop () at readline.c:656
#7  0x5574dec9 in readline_internal () at readline.c:670
#8  0x5574d57f in readline (prompt=0x60203630 "bash-4.4$
") at readline.c:374
#9  0x555e2695 in yy_readline_get () at ./parse.y:1451
#10 0x555e286d in yy_readline_get () at ./parse.y:1482
#11 0x555e24f8 in yy_getc () at ./parse.y:1384
#12 0x555e4842 in shell_getc (remove_quoted_newline=1) at ./parse.y:2284
#13 0x555e72d4 in read_token (command=0) at ./parse.y:3133
#14 0x555e5cb1 in yylex () at ./parse.y:2670
#15 0x555daa62 in yyparse () at y.tab.c:1824
#16 0x555d9c33 in parse_command () at eval.c:294
#17 0x555d9e88 in read_command () at eval.c:338
#18 0x555d90c4 in reader_loop () at eval.c:140
#19 0x555d486e in main (argc=3, argv=0x7fffe478,
env=0x7fffe498) at shell.c:794

(gdb) frame 1
#1  0x556c88bb in maybe_make_readline_line (new_line=0x0) at
bashline.c:2548
2548  if (strcmp (new_line, rl_line_buffer) != 0)
(gdb) frame 2
#2  0x556cec8a in bash_execute_unix_command (count=1, key=13)
at bashline.c:4142
4142  maybe_make_readline_line (v ? value_cell (v) : 0);

I tried the following patch:

dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
diff --git a/bashline.c b/bashline.c
index 129714aa..7884416a 100644
--- a/bashline.c
+++ b/bashline.c
@@ -2545,7 +2545,7 @@ static void
 maybe_make_readline_line (new_line)
  char *new_line;
 {
-  if (strcmp (new_line, rl_line_buffer) != 0)
+  if (new_line && strcmp (new_line, rl_line_buffer) != 0)
 {
   rl_point = rl_end;

Which gets rid of the null pointer deference, but it seems to leave
the terminal in a bad state, so the patch is not complete and I have
no clue why.

Re: Curious case of arithmetic expansion

[Eduardo Bustamante]

On Sun, Apr 23, 2017 at 3:25 PM, Florian Mayer  wrote:
[...]
> Why not? Why is it not reasonable to expect an intuitive
> result from (())? The most intuitive thing, in my opinion,
> would be to use nameref for side effects by default, because in order
> to get a value from an id, (()) already follows namerefs.

First, the documented behavior
(https://www.gnu.org/software/bash/manual/html_node/Shell-Arithmetic.html#Shell-Arithmetic)
is this:

| The *value* of a variable is evaluated as an arithmetic expression
when it is referenced,
| or when a variable which has been given the integer attribute using
‘declare -i’ is
| assigned a value

(emphasis is mine)

Second, every other major shell that implements recursive evaluation
of arithmetical expressions behaves the same way as bash:

| dualbus@debian:~$ for sh in dash mksh zsh ksh93 posh 'busybox sh'
bash; do $sh -c 'a=b b=2; echo $((a++)) $a $b'; done
| dash: 1: Illegal number: b
| 2 3 2
| 2 3 2
| 2 3 2
| 2 3 2
| 2 3 2
| 2 3 2
|
| dualbus@debian:~$ dpkg -l dash mksh zsh ksh posh busybox bash
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| ||/ NameVersionArchitecture
 Description
| 
+++-===-==-==-
| ii  bash4.4-4+b1   amd64
 GNU Bourne Again SHell
| ii  busybox 1:1.22.0-19+b2 amd64
 Tiny utilities for small and embedded systems
| ii  dash0.5.8-2.4  amd64
 POSIX-compliant shell
| ii  ksh 93u+20120801-2+b1  amd64
 Real, AT version of the Korn shell
| ii  mksh54-2+b2amd64
 MirBSD Korn Shell
| ii  posh0.12.6+b1  amd64
 Policy-compliant Ordinary SHell
| ii  zsh 5.3.1-4amd64
 shell with lots of features

And third, you haven't really made a compelling argument to change
this behavior. Doing so will break backwards compatibility,
compatibility with other shells that implement this feature, and in my
opinion, doesn't help much in making recursive expansion of
arithmetical expressions more "intuitive".

Why is it so important that this be changed?

Re: arithmetic problem, incorrect return code with ((var++)) when var is 0 before operation

[Eduardo Bustamante]

On Sat, Apr 22, 2017 at 12:49 PM, Andrew McGlashan
 wrote:
[...]
>
> The return code from ((i++)) operation is different when i has an
> initial value of 0.

This is not a bug.

Please read the Bash reference manual section on conditional
constructs: 
https://www.gnu.org/software/bash/manual/bash.html#index-commands_002c-conditional

| The arithmetic expression is evaluated according to the rules
described below (see Shell Arithmetic). If the value of the expression
is non-zero, the return status is 0; otherwise the return status is 1.
This is exactly equivalent to
|
| let "expression"

This is also described in other sources:

1. http://wiki.bash-hackers.org/commands/builtin/let#description
2. http://mywiki.wooledge.org/ArithmeticExpression#Arithmetic_Commands

Also see the 1st example in http://mywiki.wooledge.org/BashFAQ/105
("Why doesn't set -e (or set -o errexit, or trap ERR) do what I
expected?"), which mentions this pitfall.

You can also find extensive discussions in the bug-bash archives on
why you shouldn't be using set -e, regardless of how many "sources" on
the web claim that it helps write "robust" or "correct" shell scripts.

Re: Bug: UTF-8 expansion results in extra characters

[Eduardo Bustamante]

On Mon, Mar 6, 2017 at 6:50 AM, L A Walsh  wrote:
[...]
> echo 'あa a '|wc -m
> 6
>
> There should only be 5 characters.
use echo -n then.

$ echo -n 'あa a '|wc -m
5

Re: Broken Termcaps

[Eduardo Bustamante]

El mié., mar. 1, 2017 3:46 PM, Eduardo Bustamante <dual...@gmail.com>
escribió:

>
>
> El mié., mar. 1, 2017 3:38 PM, Lfabbro <lfabbr...@protonmail.com>
> escribió:
>
> [...]
>
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
> Bash rewrites on the same line if I exeed line terminal width lenght.
>
> [...]
>
> Do you have an exotic PS1 or PROMPT_COMMAND ?
>

Sorry, forgot to CC bug-bash

>

Re: Using Clang's static analyzer on bash

[Eduardo Bustamante]

On Wed, Apr 26, 2017 at 10:10 AM, Eduardo Bustamante <dual...@gmail.com> wrote:
[...]
> #1 optimized_assignment in variables.c does not check if xrealloc was
> successful (i.e. not NULL), so if it fails, strcpy will end up
> dereferencing a null pointer.

I just noticed that xrealloc will exit on failure, so this is not
really an issue.

AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

[Eduardo Bustamante]

dualbus@debian:~/src/gnu/bash$ xxd inputrc
: 225c 432d 2230 3030 200a "\C-"000 .

# with ASAN
dualbus@debian:~/src/gnu/bash$ ./bash --noprofile --norc -ic 'bind -f inputrc'
=
==27315==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60209bb9 at pc 0x5628fdaa420b bp 0x7ffcde1bef40 sp
0x7ffcde1bef38
READ of size 1 at 0x60209bb9 thread T0
#0 0x5628fdaa420a in rl_translate_keyseq
/home/dualbus/src/gnu/bash/lib/readline/bind.c:437
#1 0x5628fdaa2934 in rl_generic_bind
/home/dualbus/src/gnu/bash/lib/readline/bind.c:347
#2 0x5628fdaa2520 in rl_bind_keyseq
/home/dualbus/src/gnu/bash/lib/readline/bind.c:251
#3 0x5628fdaa82ab in rl_parse_and_bind
/home/dualbus/src/gnu/bash/lib/readline/bind.c:1405
#4 0x5628fdaa6103 in _rl_read_init_file
/home/dualbus/src/gnu/bash/lib/readline/bind.c:927
#5 0x5628fdaa5d4c in rl_read_init_file
/home/dualbus/src/gnu/bash/lib/readline/bind.c:870
#6 0x5628fda1901c in bind_builtin bind.def:248
#7 0x5628fd95272b in execute_builtin
/home/dualbus/src/gnu/bash/execute_cmd.c:4603
#8 0x5628fd954341 in execute_builtin_or_function
/home/dualbus/src/gnu/bash/execute_cmd.c:5101
#9 0x5628fd951bc1 in execute_simple_command
/home/dualbus/src/gnu/bash/execute_cmd.c:4389
#10 0x5628fd93fac2 in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:811
#11 0x5628fda294ae in parse_and_execute
/home/dualbus/src/gnu/bash/builtins/evalstring.c:430
#12 0x5628fd90b121 in run_one_command
/home/dualbus/src/gnu/bash/shell.c:1405
#13 0x5628fd9095fa in main /home/dualbus/src/gnu/bash/shell.c:718
#14 0x7fc1396332b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#15 0x5628fd908469 in _start (/home/dualbus/src/gnu/bash/bash+0x7f469)

0x60209bb9 is located 0 bytes to the right of 9-byte region
[0x60209bb0,0x60209bb9)
allocated by thread T0 here:
#0 0x7fc139ea0d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x5628fda18195 in xmalloc /home/dualbus/src/gnu/bash/xmalloc.c:112
#2 0x5628fdaa7e6f in rl_parse_and_bind
/home/dualbus/src/gnu/bash/lib/readline/bind.c:1372
#3 0x5628fdaa6103 in _rl_read_init_file
/home/dualbus/src/gnu/bash/lib/readline/bind.c:927
#4 0x5628fdaa5d4c in rl_read_init_file
/home/dualbus/src/gnu/bash/lib/readline/bind.c:870
#5 0x5628fda1901c in bind_builtin bind.def:248
#6 0x5628fd95272b in execute_builtin
/home/dualbus/src/gnu/bash/execute_cmd.c:4603
#7 0x5628fd954341 in execute_builtin_or_function
/home/dualbus/src/gnu/bash/execute_cmd.c:5101
#8 0x5628fd951bc1 in execute_simple_command
/home/dualbus/src/gnu/bash/execute_cmd.c:4389
#9 0x5628fd93fac2 in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:811
#10 0x5628fda294ae in parse_and_execute
/home/dualbus/src/gnu/bash/builtins/evalstring.c:430
#11 0x5628fd90b121 in run_one_command
/home/dualbus/src/gnu/bash/shell.c:1405
#12 0x5628fd9095fa in main /home/dualbus/src/gnu/bash/shell.c:718
#13 0x7fc1396332b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: heap-buffer-overflow
/home/dualbus/src/gnu/bash/lib/readline/bind.c:437 in
rl_translate_keyseq
Shadow bytes around the buggy address:
  0x0c047fff9320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9370: fa fa 07 fa fa fa 00[01]fa fa 00 fa fa fa 00 03
  0x0c047fff9380: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 00 07
  0x0c047fff9390: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff93a0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff93b0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff93c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==27315==ABORTING

# With Valgrind + without bash malloc
dualbus@debian:~/src/gnu/bash$ valgrind ./bash --noprofile --norc -ic
'bind -f inputrc'
==2112== Memcheck, a memory error detector
==2112== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et 

free(): invalid next size (fast): 0x00005555558cac00 ***

[Eduardo Bustamante]

dualbus@debian:~/src/gnu/bash$ xxd bar
: 3a22 3030 5c43 2d0a 3030 3030 3030 3030  :"00\C-.
0010: 3030 3030 3030 3030 3030 3030 3030 3030  

# With system malloc
(gdb) r --noprofile --norc -ic 'bind -f bar'
Starting program: /home/dualbus/src/gnu/bash/bash --noprofile --norc
-ic 'bind -f bar'
*** Error in `/home/dualbus/src/gnu/bash/bash': free(): invalid next
size (fast): 0x558cac00 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7767dbcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x77683f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x7768478e]
/home/dualbus/src/gnu/bash/bash(xfree+0x1f)[0x555f66b6]
/home/dualbus/src/gnu/bash/bash(rl_generic_bind+0x46)[0x5563993a]
/home/dualbus/src/gnu/bash/bash(rl_macro_bind+0x7a)[0x556398ed]
/home/dualbus/src/gnu/bash/bash(rl_parse_and_bind+0x759)[0x5563bd08]
/home/dualbus/src/gnu/bash/bash(+0xe6e40)[0x5563ae40]
/home/dualbus/src/gnu/bash/bash(rl_read_init_file+0x8a)[0x5563aca9]
/home/dualbus/src/gnu/bash/bash(bind_builtin+0x382)[0x555f6e4c]
/home/dualbus/src/gnu/bash/bash(+0x4dff1)[0x555a1ff1]
/home/dualbus/src/gnu/bash/bash(+0x4eecd)[0x555a2ecd]
/home/dualbus/src/gnu/bash/bash(+0x4d8f7)[0x555a18f7]
/home/dualbus/src/gnu/bash/bash(execute_command_internal+0x80a)[0x5559b2af]
/home/dualbus/src/gnu/bash/bash(parse_and_execute+0x548)[0x555fe1e8]
/home/dualbus/src/gnu/bash/bash(+0x2f32f)[0x5558332f]
/home/dualbus/src/gnu/bash/bash(main+0x83a)[0x555824aa]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7762d2b1]
/home/dualbus/src/gnu/bash/bash(_start+0x2a)[0x55581b6a]
=== Memory map: 
4000-5568e000 r-xp  fe:01 17570830
  /home/dualbus/src/gnu/bash/bash
5588e000-55891000 r--p 0013a000 fe:01 17570830
  /home/dualbus/src/gnu/bash/bash
55891000-5589b000 rw-p 0013d000 fe:01 17570830
  /home/dualbus/src/gnu/bash/bash
5589b000-55908000 rw-p  00:00 0  [heap]
7000-70021000 rw-p  00:00 0
70021000-7400 ---p  00:00 0
76bb8000-76bce000 r-xp  fe:01 1310769
  /lib/x86_64-linux-gnu/libgcc_s.so.1
76bce000-76dcd000 ---p 00016000 fe:01 1310769
  /lib/x86_64-linux-gnu/libgcc_s.so.1
76dcd000-76dce000 r--p 00015000 fe:01 1310769
  /lib/x86_64-linux-gnu/libgcc_s.so.1
76dce000-76dcf000 rw-p 00016000 fe:01 1310769
  /lib/x86_64-linux-gnu/libgcc_s.so.1
76dcf000-76dd9000 r-xp  fe:01 1311109
  /lib/x86_64-linux-gnu/libnss_files-2.24.so
76dd9000-76fd9000 ---p a000 fe:01 1311109
  /lib/x86_64-linux-gnu/libnss_files-2.24.so
76fd9000-76fda000 r--p a000 fe:01 1311109
  /lib/x86_64-linux-gnu/libnss_files-2.24.so
76fda000-76fdb000 rw-p b000 fe:01 1311109
  /lib/x86_64-linux-gnu/libnss_files-2.24.so
76fdb000-76fe1000 rw-p  00:00 0
76fe1000-76fec000 r-xp  fe:01 131
  /lib/x86_64-linux-gnu/libnss_nis-2.24.so
76fec000-771eb000 ---p b000 fe:01 131
  /lib/x86_64-linux-gnu/libnss_nis-2.24.so
771eb000-771ec000 r--p a000 fe:01 131
  /lib/x86_64-linux-gnu/libnss_nis-2.24.so
771ec000-771ed000 rw-p b000 fe:01 131
  /lib/x86_64-linux-gnu/libnss_nis-2.24.so
771ed000-77201000 r-xp  fe:01 1311105
  /lib/x86_64-linux-gnu/libnsl-2.24.so
77201000-77401000 ---p 00014000 fe:01 1311105
  /lib/x86_64-linux-gnu/libnsl-2.24.so
77401000-77402000 r--p 00014000 fe:01 1311105
  /lib/x86_64-linux-gnu/libnsl-2.24.so
77402000-77403000 rw-p 00015000 fe:01 1311105
  /lib/x86_64-linux-gnu/libnsl-2.24.so
77403000-77405000 rw-p  00:00 0
77405000-7740c000 r-xp  fe:01 1311107
  /lib/x86_64-linux-gnu/libnss_compat-2.24.so
7740c000-7760b000 ---p 7000 fe:01 1311107
  /lib/x86_64-linux-gnu/libnss_compat-2.24.so
7760b000-7760c000 r--p 6000 fe:01 1311107
  /lib/x86_64-linux-gnu/libnss_compat-2.24.so
7760c000-7760d000 rw-p 7000 fe:01 1311107
  /lib/x86_64-linux-gnu/libnss_compat-2.24.so
7760d000-777a2000 r-xp  fe:01 1311097
  /lib/x86_64-linux-gnu/libc-2.24.so
777a2000-779a1000 ---p 00195000 fe:01 1311097
  /lib/x86_64-linux-gnu/libc-2.24.so
779a1000-779a5000 r--p 00194000 fe:01 1311097
  /lib/x86_64-linux-gnu/libc-2.24.so
779a5000-779a7000 rw-p 00198000 fe:01 1311097
  /lib/x86_64-linux-gnu/libc-2.24.so
779a7000-779ab000 rw-p  00:00 0
779ab000-779ad000 r-xp  fe:01 1311100
  /lib/x86_64-linux-gnu/libdl-2.24.so
779ad000-77bad000 ---p 2000 fe:01 1311100
  /lib/x86_64-linux-gnu/libdl-2.24.so
77bad000-77bae000 r--p 2000 fe:01 1311100
  /lib/x86_64-linux-gnu/libdl-2.24.so
77bae000-77baf000 rw-p 3000 fe:01 1311100
  /lib/x86_64-linux-gnu/libdl-2.24.so
77baf000-77bd4000 r-xp  

Memory leak in read_history_range when history file size is zero

[Eduardo Bustamante]

dualbus@debian:~/src/gnu/bash$ ./bash --noprofile --norc -ic
'HISTFILE=/dev/null; history -r'

=
==24289==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x7efe83383d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x55a42abc3195 in xmalloc /home/dualbus/src/gnu/bash/xmalloc.c:112
#2 0x55a42ac8b2c2 in history_filename
/home/dualbus/src/gnu/bash/lib/readline/histfile.c:152
#3 0x55a42ac8bc5a in read_history_range
/home/dualbus/src/gnu/bash/lib/readline/histfile.c:280
#4 0x55a42ac8bb7e in read_history
/home/dualbus/src/gnu/bash/lib/readline/histfile.c:253
#5 0x55a42abdd23a in history_builtin history.def:273
#6 0x55a42aafd72b in execute_builtin
/home/dualbus/src/gnu/bash/execute_cmd.c:4603
#7 0x55a42aaff341 in execute_builtin_or_function
/home/dualbus/src/gnu/bash/execute_cmd.c:5101
#8 0x55a42aafcbc1 in execute_simple_command
/home/dualbus/src/gnu/bash/execute_cmd.c:4389
#9 0x55a42aaeaac2 in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:811
#10 0x55a42aaf33ac in execute_connection
/home/dualbus/src/gnu/bash/execute_cmd.c:2637
#11 0x55a42aaeb897 in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:980
#12 0x55a42abd44ae in parse_and_execute
/home/dualbus/src/gnu/bash/builtins/evalstring.c:430
#13 0x55a42aab6121 in run_one_command
/home/dualbus/src/gnu/bash/shell.c:1405
#14 0x55a42aab45fa in main /home/dualbus/src/gnu/bash/shell.c:718
#15 0x7efe82b162b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: 10 byte(s) leaked in 1 allocation(s).


Fix:

dualbus@debian:~/src/gnu/bash$ git diff -- lib/readline/histfile.c
diff --git a/lib/readline/histfile.c b/lib/readline/histfile.c
index 489801b4..66a76118 100644
--- a/lib/readline/histfile.c
+++ b/lib/readline/histfile.c
@@ -292,8 +292,10 @@ read_history_range (const char *filename, int from, int to)
   goto error_and_exit;
 }

-  if (file_size == 0)
+  if (file_size == 0) {
+FREE (input);
 return 0;  /* don't waste time if we don't have to */
+  }

 #ifdef HISTORY_USE_MMAP
   /* We map read/write and private so we can change newlines to NULs without

Re: Syntax error near unexpected token `newline' within loops

[Eduardo Bustamante]

On Mon, Apr 24, 2017 at 7:44 AM, Greg Wooledge  wrote:
[...]
> The outer (( )) in the C-style for loop already create an arithmetic
> expression context.  You don't need to use $(( )) inside them.  You can
> simply write:
>
> for (( INDEX=0; INDEX<10-${#V_NAME};; INDEX++ ))

I think this is just to show the bug. i.e. these two should do the same:

dualbus@debian:~$ bash -c 'for (( ; $(($(:))); )); do :; done'
bash: -c: line 0: syntax error near unexpected token `newline'
bash: -c: line 0: `for (( ; $(($(:))); )); do :; done'

dualbus@debian:~$ bash -c 'for (( ; $((`:`)); )); do :; done'

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

[Eduardo Bustamante]

On Thu, Apr 27, 2017 at 2:35 PM, Chet Ramey  wrote:
[...]
> Thanks for the report.  This was an easy fix. You must be fuzzing
> readline's key sequence parser.

Yes. I'm currently trying a few approaches. I got this crash from:

afl-fuzz -i i1/ -o o1/ -- ./bash/bash --noprofile --norc -ic 'bind -f @@'

After compiling with CC=afl-gcc ...

With this seed:

# cat i1/1
"\e\C-e": shell-expand-line
"\C-x(": start-kbd-macro
"\e&": tilde-expand
"\C-t": transpose-chars
"\et": transpose-words
"\C-x\C-u": undo
"\C-_": undo
"\C-u": unix-line-discard
"\C-w": unix-word-rubout
"\eu": upcase-word
"\C-y": yank
"\e.": yank-last-arg
"\e_": yank-last-arg
"\e\C-y": yank-nth-arg
"\ey": yank-pop

AddressSanitizer: heap-use-after-free _rl_free_undo_list

[Eduardo Bustamante]

dualbus@debian:~/src/gnu/bash$ xxd ../cases/1
: 3010 1f0e0...

dualbus@debian:~/src/gnu/bash$ cat -A ../cases/1
0^P^_^N

To reproduce,

- run: ./bash -c 'read -e' # it doesn't seem to happen for interactive bash
- then type the following sequence: 0 \C-p \C-_ \C-n 

(in my keyboard, \C-_ is --<->)

dualbus@debian:~/src/gnu/bash$ ./bash -c 'read -e'
0
=
==24334==ERROR: AddressSanitizer: heap-use-after-free on address
0x6030c100 at pc 0x55ad664b341d bp 0x7fff83ff6580 sp
0x7fff83ff6578
READ of size 8 at 0x6030c100 thread T0
#0 0x55ad664b341c in _rl_free_undo_list
/home/dualbus/src/gnu/bash/lib/readline/undo.c:106
#1 0x55ad664b34d6 in rl_free_undo_list
/home/dualbus/src/gnu/bash/lib/readline/undo.c:122
#2 0x55ad6646f757 in readline_internal_teardown
/home/dualbus/src/gnu/bash/lib/readline/readline.c:482
#3 0x55ad6646fccf in readline_internal
/home/dualbus/src/gnu/bash/lib/readline/readline.c:671
#4 0x55ad6646f378 in readline
/home/dualbus/src/gnu/bash/lib/readline/readline.c:374
#5 0x55ad6642a74d in edit_line read.def:1069
#6 0x55ad664281dd in read_builtin read.def:550
#7 0x55ad6633e93a in execute_builtin
/home/dualbus/src/gnu/bash/execute_cmd.c:4605
#8 0x55ad66340550 in execute_builtin_or_function
/home/dualbus/src/gnu/bash/execute_cmd.c:5103
#9 0x55ad6633ddd0 in execute_simple_command
/home/dualbus/src/gnu/bash/execute_cmd.c:4391
#10 0x55ad6632bccf in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:811
#11 0x55ad66415858 in parse_and_execute
/home/dualbus/src/gnu/bash/builtins/evalstring.c:430
#12 0x55ad662f72a1 in run_one_command
/home/dualbus/src/gnu/bash/shell.c:1405
#13 0x55ad662f577a in main /home/dualbus/src/gnu/bash/shell.c:718
#14 0x7f41165482b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#15 0x55ad662f45e9 in _start (/home/dualbus/src/gnu/bash/bash+0x7f5e9)

0x6030c100 is located 0 bytes inside of 32-byte region
[0x6030c100,0x6030c120)
freed by thread T0 here:
#0 0x7f4116db5a10 in free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1a10)
#1 0x55ad66404600 in xfree /home/dualbus/src/gnu/bash/xmalloc.c:148
#2 0x55ad664b3e4f in rl_do_undo
/home/dualbus/src/gnu/bash/lib/readline/undo.c:240
#3 0x55ad664b41aa in rl_undo_command
/home/dualbus/src/gnu/bash/lib/readline/undo.c:331
#4 0x55ad664707f2 in _rl_dispatch_subseq
/home/dualbus/src/gnu/bash/lib/readline/readline.c:851
#5 0x55ad664703cd in _rl_dispatch
/home/dualbus/src/gnu/bash/lib/readline/readline.c:797
#6 0x55ad6646fc0c in readline_internal_char
/home/dualbus/src/gnu/bash/lib/readline/readline.c:629
#7 0x55ad6646fc9e in readline_internal_charloop
/home/dualbus/src/gnu/bash/lib/readline/readline.c:656
#8 0x55ad6646fcc2 in readline_internal
/home/dualbus/src/gnu/bash/lib/readline/readline.c:670
#9 0x55ad6646f378 in readline
/home/dualbus/src/gnu/bash/lib/readline/readline.c:374
#10 0x55ad6642a74d in edit_line read.def:1069
#11 0x55ad664281dd in read_builtin read.def:550
#12 0x55ad6633e93a in execute_builtin
/home/dualbus/src/gnu/bash/execute_cmd.c:4605
#13 0x55ad66340550 in execute_builtin_or_function
/home/dualbus/src/gnu/bash/execute_cmd.c:5103
#14 0x55ad6633ddd0 in execute_simple_command
/home/dualbus/src/gnu/bash/execute_cmd.c:4391
#15 0x55ad6632bccf in execute_command_internal
/home/dualbus/src/gnu/bash/execute_cmd.c:811
#16 0x55ad66415858 in parse_and_execute
/home/dualbus/src/gnu/bash/builtins/evalstring.c:430
#17 0x55ad662f72a1 in run_one_command
/home/dualbus/src/gnu/bash/shell.c:1405
#18 0x55ad662f577a in main /home/dualbus/src/gnu/bash/shell.c:718
#19 0x7f41165482b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7f4116db5d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x55ad6640453f in xmalloc /home/dualbus/src/gnu/bash/xmalloc.c:112
#2 0x55ad664b3252 in alloc_undo_entry
/home/dualbus/src/gnu/bash/lib/readline/undo.c:75
#3 0x55ad664b33a1 in rl_add_undo
/home/dualbus/src/gnu/bash/lib/readline/undo.c:92
#4 0x55ad664b9ec1 in rl_insert_text
/home/dualbus/src/gnu/bash/lib/readline/text.c:112
#5 0x55ad664bcf22 in _rl_insert_char
/home/dualbus/src/gnu/bash/lib/readline/text.c:863
#6 0x55ad664bd2d4 in rl_insert
/home/dualbus/src/gnu/bash/lib/readline/text.c:912
#7 0x55ad664707f2 in _rl_dispatch_subseq
/home/dualbus/src/gnu/bash/lib/readline/readline.c:851
#8 0x55ad664703cd in _rl_dispatch
/home/dualbus/src/gnu/bash/lib/readline/readline.c:797
#9 0x55ad6646fc0c in readline_internal_char
/home/dualbus/src/gnu/bash/lib/readline/readline.c:629
#10 0x55ad6646fc9e in readline_internal_charloop
/home/dualbus/src/gnu/bash/lib/readline/readline.c:656
#11 0x55ad6646fcc2 in readline_internal

Re: Ignore-case option to readline disables nosort option to complete

[Eduardo Bustamante]

On Wed, May 3, 2017 at 8:59 AM, Jesper Nygårds  wrote:
> The following snippet is shows that if the readline
> option completion-ignore-case is turned on, the nosort option to complete
> has no effect:

I'm unable to reproduce this using the code from the devel branch:

bash-4.4$
GNU bash, version 4.4.12(3)-maint (x86_64-unknown-linux-gnu)
bash-4.4$ . on
bash-4.4$ bind -V | grep ignore-case
completion-ignore-case is set to `on'
bash-4.4$ foo
zoo  noo  boo
bash-4.4$ . off
bash-4.4$ bind -V | grep ignore-case
completion-ignore-case is set to `off'
bash-4.4$ foo
zoo  noo  boo
bash-4.4$ cat on
bind "set completion-ignore-case on"

_foo() {
COMPREPLY=( zoo noo boo )
return 0
}

complete -o nosort -F _foo foo
bash-4.4$ cat off
bind "set completion-ignore-case off"

_foo() {
COMPREPLY=( zoo noo boo )
return 0
}

complete -o nosort -F _foo foo
bash-4.4$ git rev-parse HEAD
2a39157723ffb7dfc597dfa46b5b6fbd93cc9ea2



I think this was fixed as a consequence of the following thread:
https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00092.html

In this commit:
http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=f698849a75fc781472806182c3dc930077a5d828

Bash parser segmentation fault

[Eduardo Bustamante]

dualbus@debian:~/src/gnu/bash$ cat -v ~/segfault
0 i[$($(0(){a[$(($(0)))}>))

dualbus@debian:~/src/gnu/bash$ xxd ~/segfault
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))


dualbus@debian:~/src/gnu/bash$ ./bash -n ~/segfault
ASAN:DEADLYSIGNAL
=
==7547==ERROR: AddressSanitizer: SEGV on unknown address
0x (pc 0x7ffa6e73f504 bp 0x7ffe0950b220 sp 0x7ffe0950a9a8
T0)
#0 0x7ffa6e73f503 in strlen (/lib/x86_64-linux-gnu/libc.so.6+0x80503)
#1 0x7ffa6eec6eec  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3beec)
#2 0x56448beffd70 in error_token_from_token parse.y:6009
#3 0x56448bf004bc in report_syntax_error parse.y:6109
#4 0x56448beffc59 in yyerror parse.y:5985
#5 0x56448beebe2b in yyparse /home/dualbus/src/gnu/bash/y.tab.c:3401
#6 0x56448bee3db2 in parse_command /home/dualbus/src/gnu/bash/eval.c:294
#7 0x56448bffef1e in parse_string
/home/dualbus/src/gnu/bash/builtins/evalstring.c:563
#8 0x56448bef7695 in xparse_dolparen parse.y:4298
#9 0x56448bf61d02 in extract_command_subst
/home/dualbus/src/gnu/bash/subst.c:1239
#10 0x56448bf62d72 in extract_delimited_string
/home/dualbus/src/gnu/bash/subst.c:1383
#11 0x56448bf658ff in skip_matched_pair
/home/dualbus/src/gnu/bash/subst.c:1793
#12 0x56448bf65cfe in skipsubscript /home/dualbus/src/gnu/bash/subst.c:1818
#13 0x56448bf03be1 in assignment /home/dualbus/src/gnu/bash/general.c:382
#14 0x56448befc714 in read_token_word parse.y:5181
#15 0x56448bef222a in read_token parse.y:3330
#16 0x56448beefea3 in yylex parse.y:2675
#17 0x56448bee4be1 in yyparse /home/dualbus/src/gnu/bash/y.tab.c:1827
#18 0x56448bee3db2 in parse_command /home/dualbus/src/gnu/bash/eval.c:294
#19 0x56448bee4007 in read_command /home/dualbus/src/gnu/bash/eval.c:338
#20 0x56448bee3243 in reader_loop /home/dualbus/src/gnu/bash/eval.c:140
#21 0x56448bede9ed in main /home/dualbus/src/gnu/bash/shell.c:794
#22 0x7ffa6e6df2b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#23 0x56448bedd5e9 in _start (/home/dualbus/src/gnu/bash/bash+0x7f5e9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
(/lib/x86_64-linux-gnu/libc.so.6+0x80503) in strlen
==7547==ABORTING



(gdb) r -n ~/segfault
Starting program: /home/dualbus/src/gnu/bash/bash -n ~/segfault

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:137
137 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:137
#1  0x55592450 in error_token_from_token (tok=281) at ./parse.y:6009
#2  0x555927d5 in report_syntax_error (message=0x0) at ./parse.y:6109
#3  0x55592379 in yyerror (msg=0x556589da "syntax error")
at ./parse.y:5985
#4  0x55588151 in yyparse () at y.tab.c:3401
#5  0x55584c74 in parse_command () at eval.c:294
#6  0x555fe53a in parse_string (string=0x558b5f46
"0(){a[$(($(0)))}>))",
from_file=0x55658f43 "command substitution", flags=77,
endp=0x7fffcf58) at evalstring.c:563
#7  0x5558dd91 in xparse_dolparen (base=0x558b5f40
"i[$($(0(){a[$(($(0)))}>))",
string=0x558b5f46 "0(){a[$(($(0)))}>))", indp=0x7fffd150,
flags=73) at ./parse.y:4298
#8  0x555bbfe7 in extract_command_subst (string=0x558b5f40
"i[$($(0(){a[$(($(0)))}>))", sindex=0x7fffd150, xflags=73)
at subst.c:1239
#9  0x555bc713 in extract_delimited_string
(string=0x558b5f40 "i[$($(0(){a[$(($(0)))}>))",
sindex=0x7fffd214,
opener=0x5565ba0f "$(", alt_opener=0x5565ba0d "(",
closer=0x5565ba0b ")", flags=9) at subst.c:1383
#10 0x555bdaa7 in skip_matched_pair (string=0x558b5f40
"i[$($(0(){a[$(($(0)))}>))", start=1, open=91, close=93, flags=0)
at subst.c:1793
#11 0x555bdc5d in skipsubscript (string=0x558b5f40
"i[$($(0(){a[$(($(0)))}>))", start=1, flags=0) at subst.c:1818
#12 0x55593d5a in assignment (string=0x558b5f40
"i[$($(0(){a[$(($(0)))}>))", flags=0) at general.c:382
#13 0x55590939 in read_token_word (character=10) at ./parse.y:5181
#14 0x5558b1b4 in read_token (command=0) at ./parse.y:3330
#15 0x55589eca in yylex () at ./parse.y:2675
#16 0x5558532a in yyparse () at y.tab.c:1827
#17 0x55584c74 in parse_command () at eval.c:294
#18 0x55584d5a in read_command () at eval.c:338
#19 0x555848cb in reader_loop () at eval.c:140
#20 0x55582617 in main (argc=3, argv=0x7fffe478,
env=0x7fffe498) at shell.c:794

Re: Inconsistent behavior between 'wait' and 'builtin wait'

[Eduardo Bustamante]

On Wed, May 3, 2017 at 8:27 AM, Chet Ramey  wrote:
> Both waits should return the same exit status. Using `builtin' should not
> conceal that aspect of wait's behavior.

FWIW, I can reproduce this in the latest devel branch:

dualbus@debian:~/src/gnu/bash$ ./bash -c 'trap : TERM; { sleep 1; kill
$$; } & wait'
here
143
dualbus@debian:~/src/gnu/bash$ ./bash -c 'trap : USR1; { sleep 1; kill
-USR1 $$; } & builtin wait'
here
^C
dualbus@debian:~/src/gnu/bash$ ./bash -c 'trap : USR1; { sleep 1; kill
-USR1 $$; } & wait $!'
here
138
dualbus@debian:~/src/gnu/bash$ ./bash -c 'trap : USR1; { sleep 1; kill
-USR1 $$; } & builtin wait $!'
here

`wait' vs `builtin wait' do not seem to be following the same code
paths. BTW, the second case (builtin wait with no pid list to wait for
causes an infinite loop here)

The prints are due to:

dualbus@debian:~/src/gnu/bash$ git diff -- builtins
diff --git a/builtins/wait.def b/builtins/wait.def
index 5deb3735..1999c8e7 100644
--- a/builtins/wait.def
+++ b/builtins/wait.def
@@ -67,6 +67,7 @@ $END
 #endif

 #include 
+#include 

 #include "../bashansi.h"

@@ -132,6 +133,7 @@ wait_builtin (list)
   interrupt_immediately++;
 #endif

+  fprintf(stderr, "here\n");
   /* POSIX.2 says:  When the shell is waiting (by means of the wait utility)
  for asynchronous commands to complete, the reception of a signal for
  which a trap has been set shall cause the wait utility to return
@@ -147,6 +149,7 @@ wait_builtin (list)
 {
   last_command_exit_signal = wait_signal_received;
   status = 128 + wait_signal_received;
+  fprintf(stderr, "%d\n", status);
   wait_sigint_cleanup ();
   WAIT_RETURN (status);
 }

Bash parser segmentation fault with arithmetic for loop

[Eduardo Bustamante]

(gdb) r -nvc 'for ((;)) do :; done&'
Starting program: /home/dualbus/src/gnu/bash/bash -nvc 'for ((;)) do :; done&'
for ((;)) do :; done&
/home/dualbus/src/gnu/bash/bash: -c: line 0: syntax error: arithmetic
expression required
/home/dualbus/src/gnu/bash/bash: -c: line 0: syntax error: `((;))'

Program received signal SIGSEGV, Segmentation fault.
0x55587a1c in yyparse () at ./parse.y:1151
1151  if ($1->type == cm_connection)
(gdb) bt
#0  0x55587a1c in yyparse () at ./parse.y:1151
#1  0x55584c74 in parse_command () at eval.c:294
#2  0x555fdfb9 in parse_and_execute (string=0x558a9340
"for ((;)) do :; done&", from_file=0x55656b50 "-c", flags=4)
at evalstring.c:346
#3  0x5558332f in run_one_command (command=0x7fffe724 "for
((;)) do :; done&") at shell.c:1405
#4  0x555824aa in main (argc=3, argv=0x7fffe468,
env=0x7fffe488) at shell.c:718

Found by fuzzing with AFL

Re: Bash parser segmentation fault

[Eduardo Bustamante]

On Wed, May 3, 2017 at 9:40 AM, Eduardo Bustamante <dual...@gmail.com> wrote:
[...]

Here are more cases, which seem to just be variations that trigger the
same bug on different paths:

dualbus@debian:~/bash-fuzzing/bash-parser$ for f in minimized/*; do
printf '\n\n%s\n' ---; cat -v "$f"; printf '\n%s\n' ---; xxd "$f";
printf '%s\n' ---; bash -n "$f"; done


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 e[$($({a[$(($(0)))}>0
))
---
: 3020 655b 2428 2428 7b61 5b24 2828 2428  0 e[$($({a[$(($(
0010: 3029 2929 7d3e 300a 2929 0)))}>0.))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 e[$($({a[$($($((}>0
))
---
: 3020 655b 2428 2428 7b61 5b24 2824 2824  0 e[$($({a[$($($
0010: 2828 2929 2929 7d3e 300a 2929((}>0.))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0&(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3026 2830 2929 297d 3e29 29 $(0&(0)))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(<()))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3c28 2929 297d 3e29 29  $(<()))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 e[$($({a[$((($(0}>0
))
---
: 3020 655b 2428 2428 7b61 5b24 2828 2824  0 e[$($({a[$((($
0010: 2830 2929 2929 7d3e 300a 2929(0}>0.))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 e[$($({a[$(($(0)))}>0
))
---
: 3020 655b 2428 2428 7b61 5b24 2828 2428  0 e[$($({a[$(($(
0010: 3029 2929 7d3e 300a 2929 0)))}>0.))
---
Segmentation fault


---
0 i[$($(0(){a[$($(0))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2428 3029 297d 3e29 29   $(0))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 i[$($(0(){a[$(($(0)))}>))
---
: 3020 695b 2428 2428 3028 297b 615b 2428  0 i[$($(0(){a[$(
0010: 2824 2830 2929 297d 3e29 29  ($(0)))}>))
---
Segmentation fault


---
0 e[$($({a[$(($(>(}>0
))
---
: 3020 655b 2428 2

Re: memory leak in bash

[Eduardo Bustamante]

On Thu, May 11, 2017 at 3:47 AM, wuzongyong (A)  wrote:
[...]
> My bash version is  version 4.2.46(1)-release, valgrind version is  3.11.0 , 
> could someone help to tell me if it is a bug please? And I wanna to know the 
> deeply level reason.

Try with a more recent version. Version 4.2.46 is a few years old now.

dualbus@debian:~$ cat script
#! /bin/bash
rc_exit ()
{
exit 0
}
rc_exit

dualbus@debian:~$ valgrind bash ./script
==14004== Memcheck, a memory error detector
==14004== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14004== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==14004== Command: bash ./script
==14004==
==14004==
==14004== HEAP SUMMARY:
==14004== in use at exit: 0 bytes in 0 blocks
==14004==   total heap usage: 482 allocs, 482 frees, 31,142 bytes allocated
==14004==
==14004== All heap blocks were freed -- no leaks are possible
==14004==
==14004== For counts of detected and suppressed errors, rerun with: -v
==14004== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

dualbus@debian:~$ bash --version
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Bash doesn't handle C with acute accent properly during readline's rl_change_case

[Eduardo Bustamante]

The C with acute accent character: https://en.wikipedia.org/wiki/%C4%86

- Upper case
dualbus@debian:~$ printf '\U0106\n'
Ć

- Lower case
dualbus@debian:~$ printf '\U0107\n'
ć

Now, in bash, if you type in ć, then run readline `upcase-word' on it,
instead of ending up with the UTF-8 multibyte string for U+0106 (0xC4
0x86), you end up with 0x07 0x87.

The parameter expansion doesn't seem to have that problem so I think
it's a bug in readline:

dualbus@debian:~/src/gnu/bash$ a=ć; echo ${a^^}
Ć

dualbus@debian:~/src/gnu/bash$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

(gdb) bt
#0  rl_change_case (count=1, op=1) at text.c:1339
#1  0x00525cad in rl_upcase_word (count=1, key=117) at text.c:1304
#2  0x004fe7a7 in _rl_dispatch_subseq (key=117, map=0x771d80
, got_subseq=0) at readline.c:851
#3  0x004fed6f in _rl_dispatch_subseq (key=27, map=0x772d90
, got_subseq=0) at readline.c:985
#4  0x004fe149 in _rl_dispatch (key=27, map=0x772d90
) at readline.c:797
#5  0x004fe0b9 in readline_internal_char () at readline.c:629
#6  0x004ff6a2 in readline_internal_charloop () at readline.c:656
#7  0x004fda12 in readline_internal () at readline.c:670
#8  0x004fd8d0 in readline (prompt=0x899ce8 "bash-4.4$ ") at
readline.c:374
#9  0x0042cae8 in yy_readline_get () at ./parse.y:1456
#10 0x00431a8b in yy_getc () at ./parse.y:1389
#11 0x00432328 in shell_getc (remove_quoted_newline=1) at ./parse.y:2289
#12 0x00430bb7 in read_token (command=0) at ./parse.y:3138
#13 0x0042c14e in yylex () at ./parse.y:2675
#14 0x00428abe in yyparse () at y.tab.c:1827
#15 0x004285ab in parse_command () at eval.c:294
#16 0x00428392 in read_command () at eval.c:338
#17 0x00428091 in reader_loop () at eval.c:140
#18 0x004253bb in main (argc=1, argv=0x7fffe498,
env=0x7fffe4a8) at shell.c:794

(gdb) p rl_line_buffer
$1 = 0x83a408 "ć"

(gdb) finish
Run till exit from #0  rl_change_case (count=1, op=1) at text.c:1339
0x00525cad in rl_upcase_word (count=1, key=117) at text.c:1304
1304  return (rl_change_case (count, UpCase));
Value returned is $2 = 0

(gdb) p rl_line_buffer
$3 = 0x83a408 "\a\207"

For some reason, rl_change_case thinks `c` is ASCII:

(gdb) call isascii((unsigned char)c)
$8 = 1

Re: read -e allows execution of commands (edit-and-execute-command) as the shell's process user

[Eduardo Bustamante]

On Tue, May 9, 2017 at 3:28 PM, Chet Ramey  wrote:
[...]
> This would be a great project for someone who wanted to help.

Thanks. I'll familiarize myself with the tools and try to send a patch.

Re: Infinite loop in rl_forward_word

[Eduardo Bustamante]

On Tue, May 9, 2017 at 9:28 AM, Eduardo Bustamante <dual...@gmail.com> wrote:
[...]

>From what I can tell, it seems like the problem is that `set-mark'
allows you to set a negative rl_mark, and then you can use
`exchange-point-and-mark' to place that negative rl_mark into
rl_point.

A simple way of breaking this is by typing:
<-><5><\C-x><\C-x><-l> inside bash, and then
continue typing into readline. Or in other words, call set-mark with
-5, then type stuff, then call exchange-point-and-mark, then type more
stuff.

I think that the fix is:

dualbus@debian:~/src/gnu/bash$ git diff -- lib/readline/text.c
diff --git a/lib/readline/text.c b/lib/readline/text.c
index 095c0ef3..115de093 100644
--- a/lib/readline/text.c
+++ b/lib/readline/text.c
@@ -1699,7 +1699,7 @@ rl_backward_char_search (int count, int key)
 int
 _rl_set_mark_at_pos (int position)
 {
-  if (position > rl_end)
+  if (position > rl_end || position < 0)
 return 1;

   rl_mark = position;
@@ -1720,7 +1720,7 @@ rl_exchange_point_and_mark (int count, int key)
   if (rl_mark > rl_end)
 rl_mark = -1;

-  if (rl_mark == -1)
+  if (rl_mark < 0)
 {
   rl_ding ();
   return 1;

Re: read -e allows execution of commands (edit-and-execute-command) as the shell's process user

[Eduardo Bustamante]

On Mon, May 8, 2017 at 3:09 PM, Chet Ramey  wrote:
> There's no compelling reason to disallow it.  If a system administrator
> wants to unbind certain readline commands (and unset INPUTRC!) to protect
> against a specific use case, he is free to do that.

I agree. I changed my mind after sending that email. I still think it
would be prudent to mention this in the docs somewhere. Perhaps a
section on "security notes" in the manual/reference? or a mention in
the FAQ?

Similar to sudo's manual page:

- http://manpages.ubuntu.com/manpages/xenial/man8/sudo.8.html#contenttoc5
- http://manpages.ubuntu.com/manpages/xenial/man8/sudo.8.html#contenttoc12

I couldn't find any decent reference online that mentions a few of the
"traps" that bash has in regards to secure programming (e.g. "don't
evaluate user supplied input in arithmetical contexts without
sanitizing!", "be careful with SHELLOPTS/xtrace/PS4!", "don't use read
-e unless you trust the user supplying the info or know how to plug
the holes", "don't evaluate user supplied regular expressions!")

And... I just realized this was discussed before here:
https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00098.html

IMO, just having it documented somewhere is good enough.

Re: Infinite loop in bash glob matching

[Eduardo Bustamante]

On Tue, May 16, 2017 at 2:36 PM, Zoltán Herczeg  wrote:
[...]
> bash version: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
> This command hangs in any directory on my machine (I don't have a directory 
> without a dot file):
>
> ls @(@()).

Yeah, I can reproduce the problem with bash 4.3.11. The empty globs
make bash get stuck inside `extglob_skipname'. This was fixed in
commit 3e8a02a68917250f088a500b09543255364f6f2b
(http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=3e8a02a68917250f088a500b09543255364f6f2b)

> Yes, glibc seems correct. Do you mean this is a bug in the shell?

I do not think it's a bug. In POSIX's "2.13.1 Patterns Matching a
Single Character"
(http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/V3_chap02.html#tag_18_13_01),

If an open bracket introduces a bracket expression as in XBD RE Bracket
Expression , except that the  character ( '!' ) shall
replace the  character ( '^' ) in its role in a non-matching
list in the regular expression notation, it shall introduce a pattern
bracket expression. A bracket expression starting with an unquoted
 character produces unspecified results. Otherwise, '[' shall
match the character itself.

Then in "9.3.5 RE Bracket Expression"
(http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap09.html#tag_09_03_05),

The character sequences "[." , "[=" , and "[:" ( 
followed by a , , or ) shall be special inside
a bracket expression and are used to delimit collating symbols, equivalence
class expressions, and character class expressions. These symbols shall be
followed by a valid expression and the matching terminating sequence ".]" ,
"=]" , or ":]" , as described in the following items.

So, from my interpretation you can't use the sequence <[><:> like
that, and you should go with Daniel's suggestion instead (i.e.
`a[[:alpha:]:abm[]')

Here's how current shells treat this situation BTW:
dualbus@debian:~$ for sh in mksh ksh93 dash posh bash; do echo $sh
$($sh -c 'case a in [[:alpha:][:]) echo y;; esac'); done
mksh
ksh93
dash y
posh
bash

dualbus@debian:~$ for sh in mksh ksh93 dash posh bash; do echo $sh
$($sh -c 'case a in [[:alpha:]:[]) echo y;; esac'); done
mksh
ksh93 y
dash y
posh
bash y

As you can see, dash is the only one that treats `[[:alpha:][:]' as
 OR <[> OR :

Segmentation fault in skip_to_delim / bash_directory_completion_hook

[Eduardo Bustamante]

dualbus@debian:~/bash-fuzzing/read-readline$ base64 <
output/17/crashes/id:000288,sig:11,src:017460+007808,op:splice,rep:8
GxEWGS8YR94ZZB6QGzeQfzcbN45kAh6QGzeQGzcbNxF//y8YRwEaHB6QG+3t7e3t7efte3t7e94u
+pYBGxsbKegDVP8BGxlgBHt7e3t7e3sQlvwAcQ7/IuAMFBAbGxsrAKEBAJqampqSljyAFH8bGxlU
9tHXllMkLZYAFxAgUxP6GhveLwCV/aAQGxsb/3///yR7e3t7e94vFAAAEP8bKgCh8QJ/GvpAFJTt
lhADVP8bG28AGwIbUyQoeRv/GvpAFJQABAIbU+KVG1QE3iYUvxQbGwAC/VNbLyZUBBsbAAL9Uxsv
G1QEGxsbG1QAQAAAl+2WEBsbGwobVABAAACD8QJ///IbkCEk+iAgVP8bG28AGwIbUyQoeRv/GvpA
FJTtlhAbGxsK6ncAEfp8fGKAf2jZAzJkUVFRUf38AJYEGwIbXRsbHwCAFAAAohD8AJYEGwL9UxsV
GwAbAGRU//9//5YE3pYUGxob3i8UlhQaVGbnJof/G4B7e/oGA1T/GxtTJAp5G/8aDBSUAAR7
/3t7e/oMFJQABHt7e3u/3hEUlhQbGxsq/4DtGxsbOBsfGxsE/+0F

Core was generated by `/home/dualbus/src/gnu/bash/bash -c read -e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x5581b1be61bf in skip_to_delim (
string=0x5581b3758f87
"${\377d/\377\241\377@\361\372\224T\355y@\226\372\224\377$(o&\225\336\277\375ST[/",
start=128,
delims=0x7fffcd21a32e "}", flags=257) at subst.c:1842
#2  0x5581b1c15c31 in bash_directory_completion_hook
(dirname=0x5581b1ecf348 ) at bashline.c:3250
#3  0x5581b1c64992 in rl_filename_completion_function (
text=0x5581b3758d08
"T\374\377\226\220\355\355\355\355\355\347\355.\336\031/dސ\220\220\220\220\220\220\067\216\216\216\216\216\216\216\220\220\220\220\220\220\220\220",
'\177' ,
"\377//\375\240${\377d/\377\241\377@\361\372\224T\355y@\226\372\224\377$(o&\225\336\277\375ST[/",
state=0) at complete.c:2506
#4  0x5581b1c6406c in rl_completion_matches (
text=0x5581b3758d08
"T\374\377\226\220\355\355\355\355\355\347\355.\336\031/dސ\220\220\220\220\220\220\067\216\216\216\216\216\216\216\220\220\220\220\220\220\220\220",
'\177' ,
"\377//\375\240${\377d/\377\241\377@\361\372\224T\355y@\226\372\224\377$(o&\225\336\277\375ST[/",
entry_function=0x5581b1c6475b ) at
complete.c:2183
#5  0x5581b1c61ee6 in gen_completion_matches (
text=0x5581b3758d08
"T\374\377\226\220\355\355\355\355\355\347\355.\336\031/dސ\220\220\220\220\220\220\067\216\216\216\216\216\216\216\220\220\220\220\220\220\220\220",
'\177' ,
"\377//\375\240${\377d/\377\241\377@\361\372\224T\355y@\226\372\224\377$(o&\225\336\277\375ST[/",
start=14, end=179, our_func=0x5581b1c6475b
,
found_quote=2, quote_char=34) at complete.c:1226
#6  0x5581b1c63aab in rl_complete_internal (what_to_do=9) at complete.c:2011
#7  0x5581b1c60c51 in rl_complete (ignore=1, invoking_key=27) at
complete.c:438
#8  0x5581b1c59a35 in _rl_dispatch_subseq (key=27,
map=0x5581b3728008, got_subseq=0) at readline.c:851
#9  0x5581b1c5a162 in _rl_subseq_result (r=-2, map=0x5581b1ec7160
, key=27, got_subseq=0) at readline.c:1050
#10 0x5581b1c59f12 in _rl_dispatch_subseq (key=27,
map=0x5581b1ec7160 , got_subseq=0) at
readline.c:986
#11 0x5581b1c59efa in _rl_dispatch_subseq (key=27,
map=0x5581b1ec6140 , got_subseq=0) at
readline.c:985
#12 0x5581b1c597ac in _rl_dispatch (key=7, map=0x5581b1ec6140
) at readline.c:797
#13 0x5581b1c59434 in readline_internal_char () at readline.c:629
#14 0x5581b1c5948c in readline_internal_charloop () at readline.c:656
#15 0x5581b1c594b0 in readline_internal () at readline.c:670
#16 0x5581b1c58ecd in readline (prompt=0x5581b1c9da2c "") at readline.c:374
#17 0x5581b1c323fa in edit_line (p=0x5581b1c9da2c "", itext=0x0)
at ./read.def:1090
#18 0x5581b1c3117c in read_builtin (list=0x0) at ./read.def:554
#19 0x5581b1bc99c7 in execute_builtin (builtin=0x5581b1c30423
, words=0x5581b36fa688, flags=64, subshell=0)
at execute_cmd.c:4605
#20 0x5581b1bca927 in execute_builtin_or_function
(words=0x5581b36fa688, builtin=0x5581b1c30423 , var=0x0,
redirects=0x0, fds_to_close=0x5581b36f9e08, flags=64) at execute_cmd.c:5103
#21 0x5581b1bc92a9 in execute_simple_command
(simple_command=0x5581b36f9d88, pipe_in=-1, pipe_out=-1, async=0,
fds_to_close=0x5581b36f9e08) at execute_cmd.c:4391
#22 0x5581b1bc29df in execute_command_internal
(command=0x5581b36f9d48, asynchronous=0, pipe_in=-1, pipe_out=-1,
---Type  to continue, or q  to quit---
fds_to_close=0x5581b36f9e08) at execute_cmd.c:811
#23 0x5581b1c292f6 in parse_and_execute (string=0x5581b36e2268
"read -e", from_file=0x5581b1c86630 "-c", flags=4)
at evalstring.c:430
#24 0x5581b1ba9ce5 in run_one_command (command=0x7fffcd21c727
"read -e") at shell.c:1405
#25 0x5581b1ba8e04 in main (argc=3, argv=0x7fffcd21af28,
env=0x7fffcd21af48) at shell.c:718

I think this is the fix:

dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
diff --git a/bashline.c b/bashline.c
index 7884416a..c92255d6 100644
--- a/bashline.c
+++ b/bashline.c
@@ -3247,7 +3247,7 @@ bash_directory_completion_hook (dirname)
  char delims[2];

Segmentation fault in expassign when PS1='$[U[0S]+=]'

[Eduardo Bustamante]

Starting program: /home/dualbus/src/gnu/bash/bash
bash-4.4$ PS1='$[U[0S]+=]'
bash: 0S: value too great for base (error token is "0S")
bash: : syntax error in expression (error token is "U")
$[U[0S]+=]
bash: 0S: value too great for base (error token is "0S")

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x555b1ff7 in expassign () at expr.c:505
#2  0x555b1f4b in expcomma () at expr.c:467
#3  0x555b1ec2 in subexpr (expr=0x5596a148 "U[0S]+=") at expr.c:449
#4  0x555b1d51 in evalexp (expr=0x5596a148 "U[0S]+=",
flags=1, validp=0x7fffbff0) at expr.c:414
#5  0x555d0a73 in param_expand (string=0x5596a0a8
"$[U[0S]+=]", sindex=0x7fffc0e8, quoted=1, expanded_something=0x0,
contains_dollar_at=0x7fffc0dc,
quoted_dollar_at_p=0x7fffc0e4, had_quoted_null_p=0x7fffc0e0,
pflags=0) at subst.c:9159
#6  0x555d1c27 in expand_word_internal (word=0x7fffc1f0,
quoted=1, isexp=0, contains_dollar_at=0x0,
expanded_something=0x0) at subst.c:9655
#7  0x555c4c79 in expand_prompt_string (string=0x5596a188
"$[U[0S]+=]", quoted=1, wflags=0) at subst.c:3785
#8  0x555934b7 in decode_prompt_string (string=0x5596a393
"\v") at ./parse.y:5961
#9  0x55592479 in prompt_again () at ./parse.y:5472
#10 0x5558ab70 in yylex () at ./parse.y:2677
#11 0x55585e34 in yyparse () at y.tab.c:1821
#12 0x55585772 in parse_command () at eval.c:294
#13 0x55585858 in read_command () at eval.c:338
#14 0x555853b1 in reader_loop () at eval.c:140
#15 0x55582f71 in main (argc=1, argv=0x7fffe478,
env=0x7fffe488) at shell.c:794

(gdb) frame 1
#1  0x555b1ff7 in expassign () at expr.c:505
505   lhs = savestring (tokstr);
(gdb) p tokstr
$5 = 0x0

I still don't understand why this isn't triggered by:

bash-4.4$ "$[U[0S]+=]"
bash: 0S: value too great for base (error token is "0S")

It seems like the array index expression causes a longjmp in the
second case, so it stops evaluating.

Found by fuzzing.

I think this might be similar to
https://lists.gnu.org/archive/html/bug-bash/2017-05/msg00046.html
(i.e. ``Segmentation fault in evalerror when xtrace and
PS4='$[T[$]]'``)

I think the fix *may* be something like:

dualbus@debian:~/src/gnu/bash$ git diff -- expr.c
diff --git a/expr.c b/expr.c
index 1770cc00..d6c50571 100644
--- a/expr.c
+++ b/expr.c
@@ -494,6 +494,8 @@ expassign ()

   if (lasttok != STR)
evalerror (_("attempted assignment to non-variable"));
+  if (!tokstr)
+   evalerror (_("XXX"));

   if (special)
{

But I don't know.

Re: Compiling bash statically in 4.2/4.3/4.4 with GCC 6.1.0

[Eduardo Bustamante]

FWIW, I'm able to compile bash statically with:

dualbus@debian:~/src/gnu/bash$ ./configure --enable-static-link
--without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make
[...]
dualbus@debian:~/src/gnu/bash$ file bash
bash: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
BuildID[sha1]=183cd0733ecc4aae4d60226fd419c616cfcc5f57, not stripped
dualbus@debian:~/src/gnu/bash$ ./bash --version
GNU bash, version 4.4.12(2)-maint (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

In my system (Debian), libc.a is provided by libc6-dev:

dualbus@debian:~/src/gnu/bash$ dpkg -S /usr/lib/x86_64-linux-gnu/libc.a
libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a

dualbus@debian:~/src/gnu/bash$ gcc --version
gcc (Debian 6.3.0-16) 6.3.0 20170425
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


It fails if I try to use clang though:

dualbus@debian:~/src/gnu/bash$ CC=clang ./configure
--enable-static-link --without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make
bison -y -d ./parse.y
./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
touch parser-built
rm -f mksyntax
clang -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
-DCONF_OSTYPE='"linux-gnu"'
-DCONF_MACHTYPE='"x86_64-unknown-linux-gnu"' -DCONF_VENDOR='"unknown"'
-DLOCALEDIR='"/usr/local/share/locale"' -DPACKAGE='"bash"' -DSHELL
-DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I.  -I. -I./include -I./lib
-g -O2 -Wno-parentheses -Wno-format-security   -rdynamic -g -O2
-Wno-parentheses -Wno-format-security  -static -rdynamic -g -O2
-Wno-parentheses -Wno-format-security  -o mksyntax ./mksyntax.c
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer
equality in 
`/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../x86_64-linux-gnu/libc.a(strcmp.o)'
can not be used when making an executable; recompile with -fPIE and
relink with -pie
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:702: recipe for target 'mksyntax' failed
make: *** [mksyntax] Error 1

dualbus@debian:~/src/gnu/bash$ clang --version
clang version 3.8.1-23 (tags/RELEASE_381/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

It seems to be caused by the combination of `-static' and `rdynamic'
(from LOCAL_LDFLAGS). This "works" though:

dualbus@debian:~/src/gnu/bash$ CC=clang ./configure
--enable-static-link --without-bash-malloc
[...]
dualbus@debian:~/src/gnu/bash$ make LOCAL_LDFLAGS=
[...]
dualbus@debian:~/src/gnu/bash$ file ./bash
./bash: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
BuildID[sha1]=26ee2a8080868b2923e21f3c17c6814ae30905fb, not stripped
dualbus@debian:~/src/gnu/bash$ ./bash --version
GNU bash, version 4.4.12(1)-maint (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 7:42 AM, Eduardo Bustamante <dual...@gmail.com> wrote:
[...]
> Bash is still in `parse_matched_pair'-

This *seems* to fix it, but I actually have no clue if this is
correct, or if more cleanup is required prior to the longjmp. I also
removed `rl_forced_update_display ()', because otherwise Bash will
display an awkward PS2 just before displaying PS1 again.

dualbus@debian:~/src/gnu/bash$ git diff -- bashline.c
diff --git a/bashline.c b/bashline.c
index 7884416a..1b59af91 100644
--- a/bashline.c
+++ b/bashline.c
@@ -937,7 +937,6 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)
 {
   char *command, *metaval;
   int r, rrs, metaflag;
-  sh_parser_state_t ps;

   rrs = rl_readline_state;
   saved_command_line_count = current_command_line_count;
@@ -973,9 +972,7 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)

   if (rl_deprep_term_function)
 (*rl_deprep_term_function) ();
-  save_parser_state ();
   r = parse_and_execute (command, (editing_mode == VI_EDITING_MODE) ?
"v" : "C-xC-e", SEVAL_NOHIST);
-  restore_parser_state ();
   if (rl_prep_term_function)
 (*rl_prep_term_function) (metaflag);

@@ -989,7 +986,7 @@ edit_and_execute_command (count, c, editing_mode,
edit_command)
   rl_done = 0;
   rl_readline_state = rrs;

-  rl_forced_update_display ();
+  jump_to_top_level (DISCARD);

   return r;
 }

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 8:35 AM, Chet Ramey  wrote:
[...]
> The command is executed in a separate context, exactly the same as
> running fc on a command from the history file (in fact, that's what
> happens).  It's meant to not affect the contents of the current
> command line. That's how Posix specifies it.

Hm, I'm reading:

1. 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_03
"Command Line Editing (vi-mode)"
2. 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_05
"vi Line Editing Command Mode"
3. And http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html

I find:

(from 2, i.e. command mode)
| [number]v
| Invoke the vi editor to edit the current command line in a temporary
file. When
| the editor exits, the commands in the temporary file shall be executed and
| placed in the command history. If a number is included, it specifies the
| command number in the command history to be edited, rather than the current
| command line.

(from 1, i.e. vi-mode)
| If sh receives a SIGINT signal in command mode (whether generated by
typing the
| interrupt character or by other means), it shall terminate command
line editing
| on the current command line, reissue the prompt on the next line of the
| terminal, and reset the command history (see fc) so that the most recently
| executed command is the previous command (that is, the command that was being
| edited when it was interrupted is not re-entered into the history).

(from 3, i.e fc)
| -e  editor
| Use the editor named by editor to edit the commands. The editor string is a
| utility name, subject to search via the PATH variable (see XBD Environment
| Variables). The value in the FCEDIT variable shall be used as a
default when -e
| is not specified. If FCEDIT is null or unset, ed shall be used as the editor.

But other than that, I can't find any reference from POSIX that
mandates that the edit line must be restored after running the `v'
command.

Also, if you run `edit-and-execute-command' when the edit line as a
simple command (say ls), it will run ls, and then clear the edit line.

Reviewing what other shells do:

- ksh93: It won't accept the `v' command while under the secondary prompt
- mksh: Same as ksh93
- dash (compiled with libedit support): If you type  then
return, then ESC-v, it will open the editor on an empty file, and...
well, it nothing of what it does really makes sense.
- zsh's ZLE `edit-command-line': This one works a little different,
since it won't execute the command after the editor exits. Rather,
it'll just put the result in the edit buffer, and then you have to hit
return to execute it.
- posh: doesn't seem to support command line editing.
- NetBSD's /bin/sh: if you run the `v' command while under the
secondary prompt, it will open an editor, but discards what you write
after the editor exits and returns back to the secondary prompt state.

So there doesn't seem to be consensus here.

And I guess that it's more useful if `edit-and-execute-command'
behaves the same way for a single line command or a multiline command.

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 9:44 AM, Eduardo Bustamante <dual...@gmail.com> wrote:
[...]
> - dash (compiled with libedit support): If you type  then
> return, then ESC-v, it will open the editor on an empty file, and...
> well, it nothing of what it does really makes sense.
[...]
> - NetBSD's /bin/sh: if you run the `v' command while under the
> secondary prompt, it will open an editor, but discards what you write
> after the editor exits and returns back to the secondary prompt state.

Small correction, these two behave in the same way.

Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

This issue came up in the following help-bash thread:
http://lists.gnu.org/archive/html/help-bash/2017-05/msg1.html

Write:  then hit return. Bash will output the secondary
prompt, because it expects the user to close the single quote. Run
`edit-and-execute-command' to fix the input (e.g. ). Bash
will then execute the command, but it'll output the secondary prompt
again, expecting the user to close the single quote.

bash-4.4$ echo '
>
echo 'x'
x
>
Program received signal SIGINT, Interrupt.
0x776ee2b1 in __pselect (nfds=1, readfds=0x7fffccb8,
writefds=0x0, exceptfds=0x0, timeout=,
sigmask=0x8101f8 <_rl_orig_sigset>) at
../sysdeps/unix/sysv/linux/pselect.c:69
69  ../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.

(gdb) bt
#0  0x776ee2b1 in __pselect (nfds=1, readfds=0x7fffccb8,
writefds=0x0, exceptfds=0x0, timeout=,
sigmask=0x8101f8 <_rl_orig_sigset>) at
../sysdeps/unix/sysv/linux/pselect.c:69
#1  0x00520e32 in rl_getc (stream=0x779a58c0
<_IO_2_1_stdin_>) at input.c:515
#2  0x005217cb in rl_read_key () at input.c:481
#3  0x004fe038 in readline_internal_char () at readline.c:570
#4  0x004ff7c2 in readline_internal_charloop () at readline.c:656
#5  0x004fdb32 in readline_internal () at readline.c:670
#6  0x004fd9f0 in readline (prompt=0x88d6e8 "> ") at readline.c:374
#7  0x0042cb08 in yy_readline_get () at ./parse.y:1464
#8  0x0042cc59 in yy_readline_get () at ./parse.y:1495
#9  0x00431aab in yy_getc () at ./parse.y:1397
#10 0x00432348 in shell_getc (remove_quoted_newline=0) at ./parse.y:2297
#11 0x00436708 in parse_matched_pair (qc=39, open=39,
close=39, lenp=0x7fffd164, flags=0) at ./parse.y:3430
#12 0x00433215 in read_token_word (character=39) at ./parse.y:4857
#13 0x00431768 in read_token (command=0) at ./parse.y:3338
#14 0x0042c16e in yylex () at ./parse.y:2683
#15 0x00428abe in yyparse () at y.tab.c:1821
#16 0x004285ab in parse_command () at eval.c:294
#17 0x00428392 in read_command () at eval.c:338
#18 0x00428091 in reader_loop () at eval.c:140
#19 0x004253bb in main (argc=1, argv=0x7fffe498,
env=0x7fffe4a8) at shell.c:794

Bash is still in `parse_matched_pair'-

Re: unalias works weirdly inside an if-then block

[Eduardo Bustamante]

On Fri, May 12, 2017 at 7:33 AM, Gabor Burjan  wrote:
[...]
> Description:
> unalias works weirdly inside an if-then block

It's not just an if-then block. It's any kind of block:

 dualbus@debian:~$ bash alias
 + shopt -s expand_aliases
 + alias 'x=echo x'
 + echo x
 x
 + unalias x
 + echo x
 x
 + x
 alias: line 9: x: command not found

 dualbus@debian:~$ cat alias
 set -x
 shopt -s expand_aliases
 alias x='echo x'
 x
 {
  unalias x
  x
 }
 x

This is explained in the ALIASES section of the bash manual:

| The rules concerning the definition and use of aliases are somewhat
confusing.  Bash always reads  at  least  one  complete
| line  of input before executing any of the commands on that line.
Aliases are expanded when a command is read, not when it
| is executed.  Therefore, an alias definition appearing on the same
line as another command does not take effect  until  the
| next  line  of  input is read.  The commands following the alias
definition on that line are not affected by the new alias.
| This behavior is also an issue when functions are executed.  Aliases
are expanded when a function definition is  read,  not
| when  the  function is executed, because a function definition is
itself a command.  As a consequence, aliases defined in a
| function are not available until after that function is executed.
To be safe, always put alias definitions on  a  separate
| line, and do not use alias in compound commands.

(the key part here is that aliases are expanded when a command is
read, not when it's executed. Bash needs to parse the whole block, at
which point the alias is expanded. The unalias is not executed but
until after).

Bash segmentation fault in readline's update_line

[Eduardo Bustamante]

dualbus@debian:~/bash-fuzzing/read-readline$ base64 update_line 秧秧秧
MBs4MOenpzAwMDAwMDAwMBs4OOenpwESGQ==

Core was generated by `/home/dualbus/src/gnu/bash/bash -c read -e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:693
693 ../sysdeps/x86_64/multiarch/memcmp-sse4.S: No such file or directory.
(gdb) bt
#0  __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:693
#1  0x00519270 in update_line (
old=0x143c0c7 '秧' , "0", '秧' , ...,
new=0x143b0c7 '秧' , "0", '秧' , ...,
current_line=1, omax=-42, nmax=-42, inv_botlin=5) at display.c:1609
#2  0x00516b5a in rl_redisplay () at display.c:1121
#3  0x00514f04 in rl_display_search (search_string=0x1439808
"0", '秧' , ...,
flags=3, where=-1) at isearch.c:198
#4  0x00514d52 in _rl_isearch_dispatch (cxt=0x1438508, c=25)
at isearch.c:718
#5  0x005138c0 in rl_search_history (direction=-1,
invoking_key=18) at isearch.c:762
#6  0x0051381d in rl_reverse_search_history (sign=1, key=18)
at isearch.c:136
#7  0x004fe8c7 in _rl_dispatch_subseq (key=18, map=0x772d90
, got_subseq=0) at readline.c:851
#8  0x004fe269 in _rl_dispatch (key=18, map=0x772d90
) at readline.c:797
#9  0x004fe1d9 in readline_internal_char () at readline.c:629
#10 0x004ff7c2 in readline_internal_charloop () at readline.c:656
#11 0x004fdb32 in readline_internal () at readline.c:670
#12 0x004fd9f0 in readline (prompt=0x5513f9 "") at readline.c:374
#13 0x004cd106 in edit_line (p=0x5513f9 "", itext=0x0) at
./read.def:1090
#14 0x004cbc33 in read_builtin (list=0x0) at ./read.def:554
#15 0x0044efcf in execute_builtin (builtin=0x4cada0
, words=0x13dc688, flags=64, subshell=0)
at execute_cmd.c:4605
#16 0x0044e400 in execute_builtin_or_function
(words=0x13dc688, builtin=0x4cada0 , var=0x0,
redirects=0x0,
fds_to_close=0x13dbe08, flags=64) at execute_cmd.c:5103
#17 0x004470b5 in execute_simple_command
(simple_command=0x13dbd88, pipe_in=-1, pipe_out=-1, async=0,
fds_to_close=0x13dbe08)
at execute_cmd.c:4391
#18 0x00444b91 in execute_command_internal (command=0x13dbd48,
asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x13dbe08) at execute_cmd.c:812
#19 0x004c1ff7 in parse_and_execute (string=0x13c4268 "read
-e", from_file=0x535c9f "-c", flags=4) at evalstring.c:430
#20 0x004271af in run_one_command (command=0x7ffc7981a719
"read -e") at shell.c:1405
#21 0x004251fd in main (argc=3, argv=0x7ffc79818ea8,
env=0x7ffc79818ec8) at shell.c:718


(gdb) p old
$1 = 0x8880c7 '秧' , "0", '秧' , ...
(gdb) p new
$2 = 0x8870c7 '秧' , "0", '秧' , ...
(gdb) call strlen(old)
$3 = 859
(gdb) call strlen(new)
$4 = 859
(gdb) p temp
$5 = -42

Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'

[Eduardo Bustamante]

On Fri, May 12, 2017 at 10:29 AM, Chet Ramey  wrote:
[...]
> Because it doesn't say the equivalent of "execute the current command
> line" (as newline does), it's a standard editing command that continues
> with the current line buffer. The only thing that gets executed are the
> contents of the temp file.

I'm not yet convinced. From what I can tell from the standard, there
are two basic concepts:

- the edit line (rl_line_buffer i guess)
- the current command line

>From my reading of PS2's description, the current command line is not
necessarily a single line. i.e. PS2 will show if the current command
line is incomplete. So, the current command line is whatever the shell
has parsed up until now, even if that spans multiple lines.

Also, the `v' command indicates that it operates on the *current
command line* (which if my reading is correct, includes the current
edit line plus anything that the parser has accumulated).

Also, there's another paragraph that mentions that any command that
modifies the current line (which I assume refers to the current
command line), will cause the edit line to be replaced by the current
line.


I won't pursue this matter any further though. I think of this of a
minor inconvenience and it's not big of a deal. I usually just run
`edit-and-execute-command' on an empty line anyways :)

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

| PS2
| Each time the user enters a  prior to completing a command line in an
| interactive shell, the value of this variable shall be subjected to parameter
| expansion and written to standard error. The default value is "> ".
This volume
| of POSIX.1-2008 specifies the effects of the variable only for systems
| supporting the User Portability Utilities option.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_05

| [number]v
| Invoke the vi editor to edit the current command line in a temporary
file. When
| the editor exits, the commands in the temporary file shall be executed and
| placed in the command history. If a number is included, it specifies the
| command number in the command history to be edited, rather than the current
| command line.

| If the current line is not the edit line, any command that modifies
the current
| line shall cause the content of the current line to replace the content of the
| edit line, and the current line shall become the edit line

Re: How to call a bash-func from readline? && how to call rl-func from bash?

[Eduardo Bustamante]

On Sat, May 13, 2017 at 5:14 PM, L A Walsh  wrote:
> How might one programatically call a bash
> function from readline, and pass information from that function
> back into readline?

For that, you'd use a combination of `bind -x', READLINE_LINE and
READLINE_POINT. For example, if you wanted a key sequence to uppercase
the whole rl_line_buffer (READLINE_LINE), then you'd:

dualbus@debian:~$ upcase(){ READLINE_LINE=${READLINE_LINE^^}; }
dualbus@debian:~$ bind -x '"\C-x\C-u": upcase'
dualbus@debian:~$ foo bar baz
dualbus@debian:~$ FOO BAR BAZ

So READLINE_LINE is GNU Readline's `char * rl_line_buffer' <> and READLINE_POINT is `int rl_point' <>.

You can do a lot of things with these two alone. I guess you can
emulate most of Readline's functions with these three alone.

> Also, is it possible to define a readline
> function, or only use predefined ones?

I have been wondering about that same thing today. i.e. a builtin that
allows you to call readline functions from shell functions, e.g. to
avoid re-implementing things like `tilde-expand'.

> Ex:  On a keypress, I would like to be able to
> redefine that key in ".bashrc" and have it call a
> bash-function that could map the key to itself or
> a sequence of keys based on the shell's current state.

I don't understand this part.

Re: Segfault when closing piped stdin on 4.4.11

[Eduardo Bustamante]

On Mon, May 15, 2017 at 8:09 PM, Elliott Cable  wrote:
> I'm no shell-script master, but this is segfaulting my Bash, and I was
> able to reproduce it on a couple different systems (including the #bash
> shbot :P):
>
> echo '_() { exec <&- ;}; _ "$0" "$@"' >bleh.sh
> cat bleh.sh | bash

It's worth noting that this was fixed in the `devel' branch as a
result of the following report:
https://lists.gnu.org/archive/html/bug-bash/2017-03/msg00088.html

dualbus@debian:~/src/gnu/bash$ ./bash <<< 'exec <&-'
Segmentation fault (core dumped)

[New LWP 7237]
Core was generated by `./bash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x563a97cb9b2b in buffered_getchar () at input.c:565
565   return (bufstream_getc (buffers[bash_input.location.buffered_fd]));
(gdb) bt
#0  0x563a97cb9b2b in buffered_getchar () at input.c:565
#1  0x563a97c6d23a in yy_getc () at
/usr/homes/chet/src/bash/src/parse.y:1390
#2  0x563a97c6e12b in shell_getc (remove_quoted_newline=1) at
/usr/homes/chet/src/bash/src/parse.y:2299
#3  0x563a97c6f654 in read_token (command=0) at
/usr/homes/chet/src/bash/src/parse.y:3115
#4  0x563a97c6ebed in yylex () at /usr/homes/chet/src/bash/src/parse.y:2675
#5  0x563a97c6a251 in yyparse () at y.tab.c:1834
#6  0x563a97c69ecd in parse_command () at eval.c:261
#7  0x563a97c69fb3 in read_command () at eval.c:305
#8  0x563a97c69bf7 in reader_loop () at eval.c:149
#9  0x563a97c677fa in main (argc=1, argv=0x7ffd0dc0b498,
env=0x7ffd0dc0b4a8) at shell.c:792

(gdb) p bash_input.location.buffered_fd
$1 = 0
(gdb) p buffers[0]
$2 = (BUFFERED_STREAM *) 0x0

i.e. the problem is that the `exec <&-' closes stdin, which is the
file descriptor bash is using to read the code. So the parser tries to
read more code, and ends up dereferencing a NULL pointer.

Commit f698849a75fc781472806182c3dc930077a5d828 in the `devel' branch
adds the NULL pointer check to bufstream_ungetc (`bp == 0') before
dereferencing the `bp' pointer.

dualbus@debian:~/src/gnu/bash$ git show
f698849a75fc781472806182c3dc930077a5d828 -- input.c
commit f698849a75fc781472806182c3dc930077a5d828
Author: Chet Ramey 
Date:   Mon Mar 20 16:30:10 2017 -0400

commit bash-20170317 snapshot

diff --git a/input.c b/input.c
index ffd0c4b8..6d0e6871 100644
--- a/input.c
+++ b/input.c
@@ -525,7 +525,7 @@ bufstream_ungetc(c, bp)
  int c;
  BUFFERED_STREAM *bp;
 {
-  if (c == EOF || bp->b_inputp == 0)
+  if (c == EOF || bp == 0 || bp->b_inputp == 0)
 return (EOF);

   bp->b_buffer[--bp->b_inputp] = c;
@@ -556,6 +556,9 @@ buffered_getchar ()
 {
   CHECK_TERMSIG;

+  if (bash_input.location.buffered_fd < 0 ||
buffers[bash_input.location.buffered_fd] == 0)
+return EOF;
+
 #if !defined (DJGPP)
   return (bufstream_getc (buffers[bash_input.location.buffered_fd]));
 #else

Infinite loop in rl_forward_word

[Eduardo Bustamante]

dualbus@debian:~/bash-fuzzing/read-readline$ base64 loop
AAAbLbUA9loQGDIYLhwYGBkYGJgYGBj4FwAYYBlEAERLG0YK

dualbus@debian:~/bash-fuzzing/read-readline$ od -c loop
000  \0  \0 033   - 265  \0 366   Z 020 030   2 030   . 034 030 030
020 031 030 030 230 030 030 030 370 027  \0 030   ` 031   D  \0   D
040   K 033   F  \n
044

(gdb) r -c 'exec 

Re: Remaining memory corruption bugs in readline

[Eduardo Bustamante]

On Fri, Jun 9, 2017 at 4:59 PM, Chet Ramey  wrote:
[...]
> It's an off-by-one error.

Thank you! Do you have a patch? I want to run the patched version
against the corpus of crashing inputs that I have to see if there are
any remaining.

Re: Read builtin -e (readline) oddities

[Eduardo Bustamante]

On Mon, Jun 19, 2017 at 9:57 AM, Eduardo A. Bustamante López
 wrote:
[...]
> Hm, I can still reproduce it under Debian 9, using the `devel' branch, and I'm
> sure no startup files are being sourced.
>
>   dualbus@debian:~/src/gnu/bash-builds/devel$ ./bash --norc --noprofile
>   bash-4.4$ declare -p command-not-found
>   bash: declare: command-not-found: not found

Heh, actually:

dualbus@debian:~/src/gnu/bash-builds/devel$ ./bash --norc --noprofile
bash-4.4$ declare -fp command_not_found_handle
bash: declare: command_not_found_handle: not found

The rest is correct though.

Re: Bug in select-command

[Eduardo Bustamante]

On Sat, Jun 24, 2017 at 9:46 AM, Eduardo A. Bustamante López
 wrote:
[...]
> For some reason though, the following fails to update the value of COLUMNS:
[...]
>   echo \$- $-
>   echo cols $(tput cols)
>   command true # this should trigger?
>   select opt in "${options[@]}"; do
> break
>   done

Bah, ignore this remark. `command true' will run the builtin `true'.
The rest of my email should be accurate though.

Re: bash sigabrt

[Eduardo Bustamante]

On Tue, Jun 20, 2017 at 9:12 AM, Rajaa, Mukuntha (Nokia -
IN/Bangalore)  wrote:
> Hi,
>
> Bash-4.4.12(1) release occasionally coredumps. This was tested on mips64 
> platform. Could you please confirm, is this a known bug or should I raise a 
> ticket for this ?

This error means that bash's internal allocator found an issue
(perhaps the code is trying to `free' a memory region that was not
allocated by it) and calls `abort()' which causes the process to end.

It looks like it crashed during completion for `netst'. Can you
reproduce this consistently? And if so, how?

Re: {varname} redirection for a command or group leaves the file open

[Eduardo Bustamante]

On Fri, May 19, 2017 at 3:32 PM,   wrote:
[...]
> I'd really like to see Bash get on the right side of this issue - and
> the sooner the better.

There is no right side. Only two opposing viewpoints. I don't think
it's enough to justify the change breaking backwards compatibility.

Re: Bash feature request: provide state data pointer and unset_func for dynamic variables

[Eduardo Bustamante]

On Fri, May 19, 2017 at 12:08 PM,   wrote:
[...]
> Anyway, I thought I'd float the idea and see if it might be a
> possibility.

Feel free to send patches.

Could you provide examples on how you expect this to be used? I'm
having a hard time trying to understand how this will be used.

Builtin read with -n0 or -N0 (nchars == 0) behaves as a read with no -n/-N argument

[Eduardo Bustamante]

(I think this is a good problem for Pranav to tackle if you consider
this to be a bug, Chet).

Current behavior:

dualbus@debian:~$ bash -c 'read -n0 <<< "abc"; declare -p REPLY'
declare -- REPLY="abc"

dualbus@debian:~$ bash --version|head -n1
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu)

Expected behavior:

#1 nchars <= 0 treated as an error

i.e.

dualbus@debian:~/src/gnu/bash-build$ ./bash -c 'read -n0 <<< "abc";
declare -p REPLY'
./bash: line 0: read: 0: invalid number
./bash: line 0: declare: REPLY: not found

#2 adopt the same semantics as POSIX read(2) syscall

http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html describes:

| Before any action described below is taken, and if nbyte is zero, the read()
| function may detect and return errors as described below. In the absence of
| errors, or if error detection is not performed, the read() function shall
| return zero and have no other results.

This is what the rest of the shells that support a similar option do:

dualbus@debian:~$ for sh in bash ksh93 mksh zsh; do echo $sh $($sh -c
'set -- -n 0; [ -n "$ZSH_VERSION" ] && set -k 0; read "$@" REPLY <<<
abc; typeset -p REPLY'); done
bash declare -- REPLY="abc"
ksh93 REPLY=''
mksh typeset REPLY=
zsh typeset REPLY=''

I'm in favour of #2.

This was reported by Freenode user `mknod' in #bash

Builtin history -r does not work with named pipes (i.e. GNU readline's histfile.c read_history_range)

[Eduardo Bustamante]

(I think this is a good problem for Pranav to tackle if you consider
this to be a bug, Chet).

The problem is that fstat(2) will return an st_size of 0 if the file
is non-regular. I think that the easiest path here is to goto
`error_and_exit' if `file' is not a regular file (and perhaps print a
useful error message?).

(gdb) r -c 'history -r <(echo foo)'
Starting program: /home/dualbus/src/gnu/bash-build/bash -c 'history -r
<(echo foo)'

Breakpoint 1, read_history_range (filename=0x82a9e8 "/dev/fd/63",
from=0, to=-1) at ../../../bash/lib/readline/histfile.c:270
270   int overflow_errno = EFBIG;
(gdb) n
277   history_lines_read_from_file = 0;
(gdb) n
279   buffer = last_ts = (char *)NULL;
(gdb) n
280   input = history_filename (filename);
(gdb) n
281   file = input ? open (input, O_RDONLY|O_BINARY, 0666) : -1;
(gdb) n
283   if ((file < 0) || (fstat (file, ) == -1))
(gdb) n
286   file_size = (size_t)finfo.st_size;
(gdb) n
289   if (file_size != finfo.st_size || file_size + 1 < file_size)
(gdb) n
295   if (file_size == 0)
(gdb) n
297   free (input);
(gdb) n
298   return 0; /* don't waste time if we don't have to */

This was reported by Freenode user `merijn' in #bash

Re: PWD not made canonical on shell start

[Eduardo Bustamante]

On Tue, May 23, 2017 at 8:51 AM,   wrote:
[...]
> Bash Version: 4.3
> Patch Level: 48
> Release Status: release

I can reproduce with 4.4.11(1)-release and the latest devel branch

[...]
> As implemented, I now have to start every shell script that
> uses $PWD before using "cd" with either 'cd "$(/bin/pwd)"' or
> 'set -o physical ; cd .' to get PWD into a usable state.

As an aside: any reason you use /bin/pwd instead of the shell builtin pwd?


The problem seems to be that `sh_canonpath' is called to set the
working directory (`set_working_directory'), but the value of PWD is
not updated with the canonical version.

Here's what I think is the fix. I'm not sure if the set_auto_export is
needed, most likely it isn't.

dualbus@debian:~/src/gnu/bash$ git diff -- variables.c
diff --git a/variables.c b/variables.c
index 944de86e..e0a258dd 100644
--- a/variables.c
+++ b/variables.c
@@ -852,6 +852,8 @@ set_pwd ()
current_dir = get_working_directory ("shell_init");
   else
set_working_directory (current_dir);
+  temp_var = bind_variable ("PWD", current_dir, 0);
+  set_auto_export (temp_var);
   free (current_dir);
 }
   else if (home_string && interactive_shell && login_shell &&

Re: {varname} redirection for a command or group leaves the file open

[Eduardo Bustamante]

FWIW, this seems to "fix" the issue.

dualbus@debian:~/src/gnu/bash$ git diff -- redir.c
diff --git a/redir.c b/redir.c
index 68741dbb..8113ae3b 100644
--- a/redir.c
+++ b/redir.c
@@ -906,6 +906,7 @@ do_redirection_internal (redirect, flags)
  close (fd);
  return (r);   /* XXX */
}
+ add_undo_close_redirect (redirector);
}
  else if ((fd != redirector) && (dup2 (fd, redirector) < 0))
{
@@ -1006,6 +1007,7 @@ do_redirection_internal (redirect, flags)
  close (fd);
  return (r);   /* XXX */
}
+ add_undo_close_redirect (redirector);
}
  else if (fd != redirector && dup2 (fd, redirector) < 0)
{
@@ -1077,6 +1079,7 @@ do_redirection_internal (redirect, flags)
  close (redirector);
  return (r);   /* XXX */
}
+ add_undo_close_redirect (redirector);
}
  /* This is correct.  2>&1 means dup2 (1, 2); */
  else if (dup2 (redir_fd, redirector) < 0)

Re: Interested in contributing to Bash

[Eduardo Bustamante]

On Sun, May 21, 2017 at 5:44 AM, Pranav Deshpande
 wrote:
[...]
> Any guidance on so as how to get started? Are there any tasks that I can
> take up so that I get introduced to the code base.

My recommendations would be:

- Clone the git repository (https://savannah.gnu.org/git/?group=bash)
- Subscribe both bug-bash@gnu.org and help-b...@gnu.org. Try to
reproduce bug reports and report back the results.
- Read the mailing list archives
(https://lists.gnu.org/archive/html/bug-bash/ and
https://lists.gnu.org/archive/html/help-bash/), and take note of any
reported bugs that are not answered or fixed yet in the latest `devel'
branch of the git repository.
- Some people place bug reports in the Savannah issue tracker
(https://savannah.gnu.org/support/?group=bash). You might also want to
check there and see if any of the issues reported there are still not
fixed in the latest `devel' branch.

Re: History Feature issue

[Eduardo Bustamante]

On Sun, May 21, 2017 at 11:29 AM, Pranav Deshpande
 wrote:
> The lssue here: https://savannah.gnu.org/support/?109000 interests me.
> It's something that I have experienced while using the shell. I am
> interested in solving it

That bug report lacks detail. There are already ways of sharing
history between multiple sessions. Some of the alternatives are
outlined here: 
https://unix.stackexchange.com/questions/1288/preserve-bash-history-in-multiple-terminal-windows

Give these a try first.

> Any ideas so as how can I get started with the code base?

If you're interested in the implementation, review:

dualbus@debian:~/src/gnu/bash$ head -n1 bashhist.c builtins/history.def
==> bashhist.c <==
/* bashhist.c -- bash interface to the GNU history library. */

==> builtins/history.def <==
This file is history.def, from which is created history.c.

And if you want to go into even more detail, review the history
library as implemented by GNU readline (and bundled with bash):

dualbus@debian:~/src/gnu/bash$ head -n1 lib/readline/hist*c
==> lib/readline/histexpand.c <==
/* histexpand.c -- history expansion. */

==> lib/readline/histfile.c <==
/* histfile.c - functions to manipulate the history file. */

==> lib/readline/history.c <==
/* history.c -- standalone history library */

==> lib/readline/histsearch.c <==
/* histsearch.c -- searching the history list. */

Re: Non-empty associative array considered not-set by -v test

[Eduardo Bustamante]

On Sat, May 27, 2017 at 2:07 PM, 林博仁  wrote:
[...]

Please read the discussions in
https://lists.gnu.org/archive/html/bug-bash/2016-06/msg00067.html and
https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html

When you use an associative array without an explicit subscript, it'll
refer to the element with key '0':

$ declare -A AA=(['0']=zero ['1']=one); echo "$AA"
zero

$ declare -A AA=(['1']=one); echo "$AA"
*empty*

AddressSanitizer: heap-use-after-free ../../../bash/lib/readline/display.c:2092 in update_line

[Eduardo Bustamante]

Run with: bash -c 'read -e' < file # patched bash

File base64:

KgMSGQX//wD/NBs1NTUbNRITNTU13TVGFgkVNTU1NdA1RhYJBTUzNdA1Rp4HB2BJYAcH9QcGAAAL
C2AzNdA1Rj0HB2BJBwYAAAsLAQBgYAIAgAiZgBVZYCAbAAEArq6urq6urq6urq6u/4Cu
rq6urq6urq6urq4AAWAZGRkZ5AAQGv9AoBsF

The error under ASAN:

==31690==ERROR: AddressSanitizer: heap-use-after-free on address
0x61d1a4b8 at pc 0x561a9673234b bp 0x7ffc6b8d0db0 sp
0x7ffc6b8d0da8
READ of size 4 at 0x61d1a4b8 thread T0
#0 0x561a9673234a in update_line ../../../bash/lib/readline/display.c:2092
#1 0x561a9672e589 in rl_redisplay ../../../bash/lib/readline/display.c:1121
#2 0x561a966f7aef in _rl_internal_char_cleanup
../../../bash/lib/readline/readline.c:514
#3 0x561a966f7ec5 in readline_internal_char
../../../bash/lib/readline/readline.c:638
#4 0x561a966f7ee2 in readline_internal_charloop
../../../bash/lib/readline/readline.c:656
#5 0x561a966f7f06 in readline_internal
../../../bash/lib/readline/readline.c:670
#6 0x561a966f75bc in readline ../../../bash/lib/readline/readline.c:374
#7 0x561a966b2991 in edit_line
../../bash/builtins/../../bash/builtins/read.def:1090
#8 0x561a966b0302 in read_builtin
../../bash/builtins/../../bash/builtins/read.def:554
#9 0x561a965c6a1d in execute_builtin ../bash/execute_cmd.c:4605
#10 0x561a965c8633 in execute_builtin_or_function ../bash/execute_cmd.c:5103
#11 0x561a965c5eb3 in execute_simple_command ../bash/execute_cmd.c:4391
#12 0x561a965b3db2 in execute_command_internal ../bash/execute_cmd.c:811
#13 0x561a9669d986 in parse_and_execute ../../bash/builtins/evalstring.c:430
#14 0x561a9657f271 in run_one_command ../bash/shell.c:1405
#15 0x561a9657d74a in main ../bash/shell.c:718
#16 0x7f7ce77c72b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#17 0x561a9657c5b9 in _start
(/home/dualbus/src/gnu/bash-build-read-asan/bash+0x7f5b9)

0x61d1a4b8 is located 56 bytes inside of 2048-byte region
[0x61d1a480,0x61d1ac80)
freed by thread T0 here:
#0 0x7f7ce8035090 in realloc
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2090)
#1 0x561a9668c6a6 in xrealloc ../bash/xmalloc.c:133
#2 0x561a9672bc4c in rl_redisplay ../../../bash/lib/readline/display.c:966
#3 0x561a966f7aef in _rl_internal_char_cleanup
../../../bash/lib/readline/readline.c:514
#4 0x561a966f7ec5 in readline_internal_char
../../../bash/lib/readline/readline.c:638
#5 0x561a966f7ee2 in readline_internal_charloop
../../../bash/lib/readline/readline.c:656
#6 0x561a966f7f06 in readline_internal
../../../bash/lib/readline/readline.c:670
#7 0x561a966f75bc in readline ../../../bash/lib/readline/readline.c:374
#8 0x561a966b2991 in edit_line
../../bash/builtins/../../bash/builtins/read.def:1090
#9 0x561a966b0302 in read_builtin
../../bash/builtins/../../bash/builtins/read.def:554
#10 0x561a965c6a1d in execute_builtin ../bash/execute_cmd.c:4605
#11 0x561a965c8633 in execute_builtin_or_function ../bash/execute_cmd.c:5103
#12 0x561a965c5eb3 in execute_simple_command ../bash/execute_cmd.c:4391
#13 0x561a965b3db2 in execute_command_internal ../bash/execute_cmd.c:811
#14 0x561a9669d986 in parse_and_execute ../../bash/builtins/evalstring.c:430
#15 0x561a9657f271 in run_one_command ../bash/shell.c:1405
#16 0x561a9657d74a in main ../bash/shell.c:718
#17 0x7f7ce77c72b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

previously allocated by thread T0 here:
#0 0x7f7ce8035090 in realloc
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2090)
#1 0x561a9668c6a6 in xrealloc ../bash/xmalloc.c:133
#2 0x561a9672bc4c in rl_redisplay ../../../bash/lib/readline/display.c:966
#3 0x561a966f7aef in _rl_internal_char_cleanup
../../../bash/lib/readline/readline.c:514
#4 0x561a966f7ec5 in readline_internal_char
../../../bash/lib/readline/readline.c:638
#5 0x561a966f7ee2 in readline_internal_charloop
../../../bash/lib/readline/readline.c:656
#6 0x561a966f7f06 in readline_internal
../../../bash/lib/readline/readline.c:670
#7 0x561a966f75bc in readline ../../../bash/lib/readline/readline.c:374
#8 0x561a966b2991 in edit_line
../../bash/builtins/../../bash/builtins/read.def:1090
#9 0x561a966b0302 in read_builtin
../../bash/builtins/../../bash/builtins/read.def:554
#10 0x561a965c6a1d in execute_builtin ../bash/execute_cmd.c:4605
#11 0x561a965c8633 in execute_builtin_or_function ../bash/execute_cmd.c:5103
#12 0x561a965c5eb3 in execute_simple_command ../bash/execute_cmd.c:4391
#13 0x561a965b3db2 in execute_command_internal ../bash/execute_cmd.c:811
#14 0x561a9669d986 in parse_and_execute ../../bash/builtins/evalstring.c:430
#15 0x561a9657f271 in run_one_command ../bash/shell.c:1405
#16 0x561a9657d74a in main ../bash/shell.c:718
#17 0x7f7ce77c72b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

SUMMARY: AddressSanitizer: heap-use-after-free

Infinite loop in readline's noninc_search

[Eduardo Bustamante]

Ran: bash -c 'read -e' < file # patched read to read from file

file Base64:

L/sFfwh+NRgqGHUcb39AfxsDAAACAIABIf+qANqAABsF6+M8KDyAAP7/qgDagAAbBevj
T0wgTYAnAAIAJgkJAAD+/6r///8JCQkAAAIA5vYJCQl6GzgAvBTgJf22G4A3/xuFhYWFhYVw
hYUXhYWFhYWF/xv/QHyAFAH/G/9AZIAyAQYbGVQE3i8UlhTelmQAGiIuVBAAwxQAABAAGVMkBHt7
e5ZiaXvPLxQCElMbGxAbGlOy/xtVgBQA+BsgRgTeLxSnFAAUGxoiGqEUJIbzlgTe1hQbGjyAAP7/
qvjagAAbBSIagP8JVBMbGxkAAAD/DBSUe3t7e3t7e94vQBuampqampqampqampqampqampoM
FJR/GwIMNRsbEP8aAGckKOEbIFQm3i8UABQbGxs4ADQbGiIaoRQkhvMCGxsQVCbeLxSW
BP7WFBsUIhqA/wlUExsbGQAAAP8MFJQUGwIbTiQuJA==


000   / 373 005 177  \b   ~   5 030   * 030   u 034   o 177   @ 177
020 033 003  \0  \0 002  \0 200 001   ! 377 252  \0 332 200  \0 033
040 005 353 343  \0  \0  \0   <   (   < 200  \0 376 377 252  \0 332
060 200  \0 033 005 353 343  \0  \0  \0   O   L   M 200  \0  \0
100  \0   '  \0 002  \0   &  \t  \t  \0  \0 376 377 252 377 377 377
120  \t  \t  \t  \0  \0 002  \0 346 366  \t  \t  \t   z 033   8  \0
140 274 024 340   % 375 266 033 200   7 377 033 205 205 205 205 205
160 205   p 205 205 027 205 205 205 205 205 205 377 033 377   @   |
200 200 024 001 377 033 377   @   d 200   2 001 006 033 031   T 004
220 336   / 024 226 024 336 226   d  \0 032   "   .   T 020  \0 303
240 024  \0  \0 020  \0 031   S   $ 004   {   {   { 226   b   i   {
260 317   / 024 002 022   S 033 033 020 033 032   S 262 377 033   U
300 200 024  \0 370 033   F 004 336   / 024 247 024  \0 024 033
320 032   " 032 241 024   $ 206 363 226 004 336 326 024 033 032   <
340 200  \0 376 377 252 370 332 200  \0 033 005   " 032 200 377  \t
360   T 023 033 033 031  \0  \0  \0 377  \f 024 224   {   {   {   {
400   {   {   { 336   /   @  \0  \0  \0 033 232 232 232 232 232 232
420 232 232 232 232 232 232 232 232 232 232 232 232  \f 024 224 177
440 033 002  \f   5 033 033 020 377  \0  \0  \0 032  \0   g   $   (
460 341 033   T   & 336   / 024  \0  \0  \0  \0 024 033 033 033
500   8  \0   4 033 032   " 032 241 024   $ 206 363 002 033 033 020
520   T   & 336   / 024 226 004 376 326 024 033 024   " 032 200 377
540  \t   T 023 033 033 031  \0  \0  \0 377  \f 024 224 024 033 002
560 033   N   $   .   $
565

(gdb) bt
#0  noninc_search (dir=1, pchar=0) at ../../../bash/lib/readline/search.c:377
#1  0x561e59f688a2 in rl_noninc_forward_search (count=1, key=110)
at ../../../bash/lib/readline/search.c:396
#2  0x561e59f62a47 in _rl_dispatch_subseq (key=110,
map=0x561e5a1d0160 , got_subseq=0)
at ../../../bash/lib/readline/readline.c:851
#3  0x561e59f627be in _rl_dispatch (key=1540448632,
map=0x561e5a1d0160 )
at ../../../bash/lib/readline/readline.c:797
#4  0x561e59f62984 in _rl_dispatch_subseq (key=78,
map=0x561e5a1d0160 , got_subseq=0)
at ../../../bash/lib/readline/readline.c:840
#5  0x561e59f62f0c in _rl_dispatch_subseq (key=27,
map=0x561e5a1cf140 , got_subseq=0)
at ../../../bash/lib/readline/readline.c:985
#6  0x561e59f627be in _rl_dispatch (key=1540448632,
map=0x561e5a1cf140 )
at ../../../bash/lib/readline/readline.c:797
#7  0x561e59f62446 in readline_internal_char () at
../../../bash/lib/readline/readline.c:629
#8  0x561e59f6249e in readline_internal_charloop () at
../../../bash/lib/readline/readline.c:656
#9  0x561e59f624c2 in readline_internal () at
../../../bash/lib/readline/readline.c:670
#10 0x561e59f61edf in readline (prompt=0x561e59fa6e0c "") at
../../../bash/lib/readline/readline.c:374
#11 0x561e59f3b40c in edit_line (p=0x561e59fa6e0c "", itext=0x0)
at ../../bash/builtins/../../bash/builtins/read.def:1090
#12 0x561e59f3a18e in read_builtin (list=0x0) at
../../bash/builtins/../../bash/builtins/read.def:554
#13 0x561e59ed29c7 in execute_builtin (builtin=0x561e59f39435
, words=0x561e5bcb3648, flags=64, subshell=0)
at ../bash/execute_cmd.c:4605
#14 0x561e59ed3927 in execute_builtin_or_function
(words=0x561e5bcb3648, builtin=0x561e59f39435 , var=0x0,
redirects=0x0, fds_to_close=0x561e5bcb2de8, flags=64) at
../bash/execute_cmd.c:5103
#15 0x561e59ed22a9 in execute_simple_command
(simple_command=0x561e5bcb2d08, pipe_in=-1, pipe_out=-1, async=0,
fds_to_close=0x561e5bcb2de8) at ../bash/execute_cmd.c:4391
#16 0x561e59ecb9df in execute_command_internal
(command=0x561e5bcb2cc8, asynchronous=0, pipe_in=-1, pipe_out=-1,
fds_to_close=0x561e5bcb2de8) at ../bash/execute_cmd.c:811
#17 0x561e59f32308 in parse_and_execute (string=0x561e5bc9b268
"PATH= read -e", from_file=0x561e59f8f630 "-c", flags=4)
at ../../bash/builtins/evalstring.c:430
#18 0x561e59eb2ce5 in run_one_command (command=0x7ffdabd84755
"PATH= read -e") at ../bash/shell.c:1405
#19 0x561e59eb1e04 in main (argc=3, argv=0x7ffdabd834d8,
env=0x7ffdabd834f8) at ../bash/shell.c:718

(gdb) info locals
cxt = 0x561e5bd16108
c = -1
r = 1

It seems like noninc_search doesn't handle EOF (-1) properly, the fix
seems to be:

Re: Infinite loop in bash glob matching

[Eduardo Bustamante]

On Tue, May 16, 2017 at 2:48 AM, Zoltán Herczeg  wrote:
> Hi,
>
> bash enter an infinite loop for this glob:
>
> ls @(@()).

It works fine for me. What version of Bash are you using? And, what
files are in the directory you're testing in?

dualbus@debian:~/t$ ls
a.1  a.2  a.3  a.4  b.1  b.2  b.3  b.4  c.1  c.2  c.3  c.4  d.1  d.2  d.3  d.4
dualbus@debian:~/t$ ls @(@()).
a.1  a.2  a.3  a.4  b.1  b.2  b.3  b.4  c.1  c.2  c.3  c.4  d.1  d.2  d.3  d.4
dualbus@debian:~/t$
GNU bash, version 4.4.11(1)-release (x86_64-pc-linux-gnu)


> I have been trying to create a bash glob regex converter. It would be great 
> if somebody (privately) could explain me  how !() and invalid [] expressions 
> exactly work. I have questions such as:
>
> ls a[[:alpha:][:abm]
>
> Why does this match to a: and nothing else (e.g. am or a[mm )?

The shell globbing library seems to be interpreting this pattern
weirdly. I don't know the answer for this, but the glob() call in
glibc does what I expect:

dualbus@debian:~/t$ ls
a:  aa  ab
dualbus@debian:~/t$ ls a[[:alpha:][:abm]
a:
dualbus@debian:~/t$ ../glob
a:
aa
ab
dualbus@debian:~/t$ cat ../glob.c
#include 
#include 
#include 

int main() {
int i;
glob_t pglob;
if(glob("a[[:alpha:][:abm]", 0, NULL, ))
perror(NULL);
for(i = 0; i < pglob.gl_pathc; i++) {
puts(pglob.gl_pathv[i]);
}
return 0;
}

Re: RFE: Please allow unicode ID chars in identifiers

[Eduardo Bustamante]

On Thu, Jun 1, 2017 at 7:42 PM, L A Walsh  wrote:
> It would be a useful upgrade besides being a "good world citizen" ;-).
[...]

I honestly fail to see the usefulness of such upgrade. It'll just
increase the complexity of the parser, to get what, emojis?

Do you have an example of something that absolutely needs Unicode and
cannot be achieved by the current state of affairs? (an actual real
world use case)

Re: Builtin read with -n0 or -N0 (nchars == 0) behaves as a read with no -n/-N argument

[Eduardo Bustamante]

On Sun, Jun 4, 2017 at 12:16 AM, dualbus  wrote:
[...]
> Although there's a problem with the solution:
>
>   dualbus@debian:~$ for sh in bash ~/src/gnu/bash-build/bash ksh93 mksh; do 
> $sh -c ': | read -n 0; echo $?'; done
>   1
>   0
>   1
>   1
>
> Since the read(2) system call doesn't take place, `read -n 0' doesn't detect
> the broken pipe. IMO, it should.

Err, I'm clearly wrong. SIGPIPE is sent to the writer, not to the
reader. My bad.

That doesn't mean the problem is not there though. I think this is a
better test:

  dualbus@debian:~$ for sh in bash ksh93 mksh
~/src/gnu/bash-build/bash; do echo $sh $($sh -c 'exec < /; read -n 0;
echo $?' 2>&1); done
  bash bash: line 0: read: read error: 0: Is a directory 1
  ksh93 1
  mksh mksh: read: Is a directory 2
  /home/dualbus/src/gnu/bash-build/bash 0

Since bash "fakes" the read, it's not able to detect errors.

I currently have this:

dualbus@debian:~/src/gnu/bash$ git diff
diff --git a/builtins/read.def b/builtins/read.def
index 520a2b34..4e4c1b8a 100644
--- a/builtins/read.def
+++ b/builtins/read.def
@@ -362,10 +362,6 @@ read_builtin (list)
   input_string = (char *)xmalloc (size = 112); /* XXX was 128 */
   input_string[0] = '\0';

-  /* More input and options validation */
-  if (nflag == 1 && nchars == 0)
-goto assign_vars;  /* bail early if asked to read 0 chars */
-
   /* $TMOUT, if set, is the default timeout for read. */
   if (have_timeout == 0 && (e = get_string_value ("TMOUT")))
 {
@@ -381,6 +377,10 @@ read_builtin (list)

   begin_unwind_frame ("read_builtin");

+  /* We were asked to read 0 chars. Do error detection and bail out */
+  if (nflag == 1 && nchars == 0 && (retval=read(fd, NULL, 0)) < 0)
+goto handle_error;
+
 #if defined (BUFFERED_INPUT)
   if (interactive == 0 && default_buffered_input >= 0 && fd_is_bash_input (fd))
 sync_buffered_stream (default_buffered_input);
@@ -714,6 +714,7 @@ add_char:
 free (rlbuf);
 #endif

+handle_error:
   if (retval < 0)
 {
   t_errno = errno;


But it completely ignores the signal handling code down below.

Re: [PATCH] Memory leak in locale.c set_default_locale

[Eduardo Bustamante]

ter 
-Wno-parentheses -Wno-format-security   -o bash shell.o eval.o y.tab.o 
general.o make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o variables.o 
copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o 
mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o 
alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o  
list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o 
xmalloc.o  -lbuiltins -lglob -lsh -lreadline -lhistory -ltermcap -ltilde 
-ldl 
./lib/sh/libsh.a(tmpfile.o): In function `sh_mktmpname':
tmpfile.c:(.text+0x3e4): warning: the use of `mktemp' is dangerous, better use 
`mkstemp' or `mkdtemp'
ls -l bash
-rwxr-x--- 1 dualbus dualbus 3433608 Jun  8 09:56 bash
size bash
   textdata bss dec hex filename
2933580  297264   83904 3314748  32943c bash

dualbus@debian:~/src/gnu/bash-build$ ./bash
bash-4.4$ echo hi
hi
bash-4.4$ exit


== Valgrind / -O0 ==

dualbus@debian:~/src/gnu/bash-build$ CFLAGS='-O0 -fno-omit-frame-pointer' 
LDFLAGS= ../bash/configure --without-bash-malloc && make -j4 
[...]
rm -f bash
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde  
-L./lib/sh  -rdynamic -O0 -fno-omit-frame-pointer -Wno-parentheses 
-Wno-format-security   -o bash shell.o eval.o y.tab.o general.o make_cmd.o 
print_cmd.o  dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o 
flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o 
unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o 
assoc.o braces.o bracecomp.o bashhist.o bashline.o  list.o stringlib.o locale.o 
findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o  -lbuiltins -lglob 
-lsh -lreadline -lhistory -ltermcap -ltilde -ldl 
./lib/sh/libsh.a(tmpfile.o): In function `sh_mktmpname':
tmpfile.c:(.text+0x25e): warning: the use of `mktemp' is dangerous, better use 
`mkstemp' or `mkdtemp'
ls -l bash
-rwxr-x--- 1 dualbus dualbus 1511808 Jun  8 10:00 bash
size bash
   textdata bss dec hex filename
1286664   48380   41072 1376116  14ff74 bash

dualbus@debian:~/src/gnu/bash-build$ valgrind ./bash
==333== Memcheck, a memory error detector
==333== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==333== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==333== Command: ./bash
==333== 
bash-4.4$ echo hi
hi
bash-4.4$ exit
exit
==333== 
==333== HEAP SUMMARY:
==333== in use at exit: 347,442 bytes in 2,885 blocks
==333==   total heap usage: 4,412 allocs, 1,527 frees, 607,323 bytes allocated
==333== 
==333== LEAK SUMMARY:
==333==definitely lost: 0 bytes in 0 blocks
==333==indirectly lost: 0 bytes in 0 blocks
==333==  possibly lost: 0 bytes in 0 blocks
==333==still reachable: 347,442 bytes in 2,885 blocks
==333== suppressed: 0 bytes in 0 blocks
==333== Rerun with --leak-check=full to see details of leaked memory
==333== 
==333== For counts of detected and suppressed errors, rerun with: -v
==333== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


-- 
Eduardo Bustamante
https://dualbus.me/

Re: Trailing newlines disappear

[Eduardo Bustamante]

On Thu, Jun 8, 2017 at 3:56 PM, Greg Wooledge  wrote:
> On Thu, Jun 08, 2017 at 10:44:29PM +0200, Geir Hauge wrote:
>> You can pick one of these instead:
>>
>> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>>
>> or
>>
>> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
>
> or
>
> lambda() { local MAPFILE IFS=; mapfile < "$file"; foo="${MAPFILE[*]}"; }
> lambda
>

What's wrong with:

IFS= read -rd '' foo < "$file"

AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

[Eduardo Bustamante]

2b0)
#20 0x5633b4aba749 in _start (/home/dualbus/src/gnu/bash-build/bash+0x7f749)
0x6110977f is located 1 bytes to the left of 256-byte region 
[0x61109780,0x61109880)
allocated by thread T0 here:
#0 0x7f891ccacd28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x5633b4bcad95 in xmalloc 
(/home/dualbus/src/gnu/bash-build/bash+0x18fd95)
#2 0x5633b4c38220 in readline_initialize_everything 
(/home/dualbus/src/gnu/bash-build/bash+0x1fd220)
#3 0x5633b4c380c6 in rl_initialize 
(/home/dualbus/src/gnu/bash-build/bash+0x1fd0c6)
#4 0x5633b4ba5c28 in initialize_readline 
(/home/dualbus/src/gnu/bash-build/bash+0x16ac28)
#5 0x5633b4bf1096 in edit_line 
(/home/dualbus/src/gnu/bash-build/bash+0x1b6096)
#6 0x5633b4beeaa4 in read_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0x1b3aa4)
#7 0x5633b4b04c89 in execute_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0xc9c89)
#8 0x5633b4b0689f in execute_builtin_or_function 
(/home/dualbus/src/gnu/bash-build/bash+0xcb89f)
#9 0x5633b4b0411f in execute_simple_command 
(/home/dualbus/src/gnu/bash-build/bash+0xc911f)
#10 0x5633b4af1f42 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb6f42)
#11 0x5633b4afa82e in execute_connection 
(/home/dualbus/src/gnu/bash-build/bash+0xbf82e)
#12 0x5633b4af2d17 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb7d17)
#13 0x5633b4bdc0f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
#14 0x5633b4abd401 in run_one_command 
(/home/dualbus/src/gnu/bash-build/bash+0x82401)
#15 0x5633b4abb8da in main (/home/dualbus/src/gnu/bash-build/bash+0x808da)
#16 0x7f891c43f2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
SUMMARY: AddressSanitizer: heap-buffer-overflow 
(/home/dualbus/src/gnu/bash-build/bash+0x23ba13) in rl_tilde_expand
Shadow bytes around the buggy address:
  0x0c227fff9290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff92d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c227fff92e0: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
  0x0c227fff92f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9310: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff9320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9330: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==3340==ABORTING

INPUT
KHo0jwAIAQEB/wsLYJgAABsbGyYA2AgiGxsbALwksygoKCgoECgoKB0eHoB/iU3pABAolGCA
//0H+lwaGhjYCCIbGxsAvCSzKCgoKCgEAAAQKCgoHR4egH+JTekAEosSAEAZQDw7AAKA
HhYKGgAQAAL/gFv/AP8eHh4BJiYmJiYmJiYmJiYmMx4ZPIM8APypaOYCAI6kPBlW0Un///8A/2AE
Wx4EBEAAAyBaPQh/OHwQIBAABAAQAAIA//8AADw9C0AhGf5/AI6OozwLLz0LQFVA+RsAoAAABDwZ
GRkZGRkZGRkuGRkZGRkAQwD8jjwZEAA8/yokUo6k+xlW0QAcyARAAAMVGVY8KCooKCgoKCgoKCgo
KCgoKCgoHR4eHhgxnGA8Iz0L3d3d3d3d3d3d3d3d8t3d3d3d3d3d3d3d3d3d3d3dIAABfQQyY/wZ
ENobBQ==

-- 
Eduardo Bustamante
https://dualbus.me/

AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

[Eduardo Bustamante]

pletion 
(/home/dualbus/src/gnu/bash-build/bash+0x167a94)
#6 0x55b2ceb5c30d in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fc30d)
#7 0x55b2ceb5caef in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fcaef)
#8 0x55b2ceb5bee8 in _rl_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x1fbee8)
#9 0x55b2ceb5b727 in readline_internal_char 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb727)
#10 0x55b2ceb5b7b9 in readline_internal_charloop 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7b9)
#11 0x55b2ceb5b7dd in readline_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7dd)
#12 0x55b2ceb5ae93 in readline 
(/home/dualbus/src/gnu/bash-build/bash+0x1fae93)
#13 0x55b2ceb16136 in edit_line 
(/home/dualbus/src/gnu/bash-build/bash+0x1b6136)
#14 0x55b2ceb13aa4 in read_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0x1b3aa4)
#15 0x55b2cea29c89 in execute_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0xc9c89)
#16 0x55b2cea2b89f in execute_builtin_or_function 
(/home/dualbus/src/gnu/bash-build/bash+0xcb89f)
#17 0x55b2cea2911f in execute_simple_command 
(/home/dualbus/src/gnu/bash-build/bash+0xc911f)
#18 0x55b2cea16f42 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb6f42)
#19 0x55b2cea1f82e in execute_connection 
(/home/dualbus/src/gnu/bash-build/bash+0xbf82e)
#20 0x55b2cea17d17 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb7d17)
#21 0x55b2ceb010f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
#22 0x55b2ce9e2401 in run_one_command 
(/home/dualbus/src/gnu/bash-build/bash+0x82401)
#23 0x55b2ce9e08da in main (/home/dualbus/src/gnu/bash-build/bash+0x808da)
#24 0x7fbbd390b2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#25 0x55b2ce9df749 in _start (/home/dualbus/src/gnu/bash-build/bash+0x7f749)
0x55b2cee4cc5c is located 56 bytes to the right of global variable 
'sh_syntabsiz' defined in 'syntax.c:11:5' (0x55b2cee4cc20) of size 4
0x55b2cee4cc5c is located 4 bytes to the left of global variable 'sh_syntaxtab' 
defined in 'syntax.c:12:5' (0x55b2cee4cc60) of size 1024
SUMMARY: AddressSanitizer: global-buffer-overflow 
(/home/dualbus/src/gnu/bash-build/bash+0x17a6c9) in bash_dequote_filename
Shadow bytes around the buggy address:
  0x0ab6d9dc1930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc1940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc1950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc1960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc1970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab6d9dc1980: 00 00 00 00 04 f9 f9 f9 f9 f9 f9[f9]00 00 00 00
  0x0ab6d9dc1990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc19a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc19b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc19c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab6d9dc19d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==2732==ABORTING

INPUT
GyoQExgaNUxSAAIAAAcbVABAKwCX7ZYQGxsbChsUEDw8PEg8PP9/GfdPAABTYC48i6sB//9/YEAA
AAMbGTw8PDw8VP8BGxlgBHt7e3t7e3sQlvwAcQ7/IuAMFBAbGxsrAKEBAJqampqSljyAFH8bGxlU
9t7XllMkLZYAABAgUxP6GhveLwCV/ZYQGxsb/3///yR7e3t7e94vFAAA//8bKgCh8QJ///IbkCEk
+iADVP8bG28AGwIbUyQoeRv/GvpAFJQABAIbU+KVG1QE3iYUvxQbGwAC/VMbLxtUBBsbAAL9Uxsv
G1QEGxsbG1QAQCsAl+2WEBsbGwobFJYUGxsbSAAAQAAAg+2WEBsbGwrqdwAR+nx8YoB/aNkDMmRR
UVFR/fwAdgQbAhtdGxsfAIAUAACiEPwAlgQbAv1TGxUbABsbGVT//3//lgTelhQbGht7e/ogA1T/
GxtTJAp5G/8aDBSUAAR7/3t7e/oMFJQABHt7e3u/3hEUlhQbGxsqAKEUAoAAGxsbOBsfGxsE/+0F

-- 
Eduardo Bustamante
https://dualbus.me/

AddressSanitizer: heap-buffer-overflow in rl_delete

[Eduardo Bustamante]

yte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1736==ABORTING

INPUT
G1AKIQMMAgIAgGA8PD0LACQbJCckoAAJAAIAr1wJCT8kJySgAAkAAgCvXAkJYycgYww8PH89CyBg
BEADFRlWPEkA/wEbU4ChPAtJ//t//4A8PQtAPBkQIjyAPDwAARsAIAQgAP8AgBkQAGRgBFr9
/wDoGRAAPDw8EfyOAID/9K6urq6urq6uk66urq6urq6urq6urq6uva6uYARAAxUTVjxJAIA8
QBn8GwAgBACOjv8g//+Ojo486BkQAGRgBFoD6AAAfQRAA+g8PBkQACRSUlJSUoBSUlJSUlJS
UlJSUlJSUlJSUlJSUlJSUlJSbvIbBQ==

-- 
Eduardo Bustamante
https://dualbus.me/

AddressSanitizer: heap-buffer-overflow in rl_search_history

[Eduardo Bustamante]

 fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff92d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c227fff92e0: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
  0x0c227fff92f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9310: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff9320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9330: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==29734==ABORTING

INPUT
AAAbLbUA9loQGDIYLhwYGBkYGJgYGBj4FwAYGBgwHgAAAEAYGBgYAOADgP85+xcYGRg9C0AAlGB3
aOgDAFNgPDxg0tJMTExMTExMTEwkf//6/97g+v/6DjUAggAAcknpTE1Nj3+PzhISEgMA/xLM
zACA//8BANWAHf0AgO3AEBISEgMSQAAA8hETEhLMEgAhISEAAABkzMzMIBdlgM4SEhIDEhIS
AxJAFgDyERMSEszMf6kTEiADEhIGjwAABABb/3+AzhIS/wASEhJkj6ocAP//EIAQ6BISExKAEhoD
EhISARIDAID/AIAjErDMf6mPi4+PeY+PfwARf4DaEhISJAH6EvERjxwAf4DaEhISAwEb
AAABAPYAEhIDARsSNC0SE1Dg8GdnZ257IACPAPP/AAAGAAAD6PmAABPoIiD8//8/s//vX2eK
fxzIzoASEg4SEhIDEhISEgGPgAAACwMAAABAEhIBj48yAP//8H+A/9h/gM4SEjMDEhISAxISEhMS
EgMA/xLMzACA//8BAMyAHf0AgADOEhIzAxISEgMSEhITEhIDAP8SzMwAgP//AQDMgB397cAQ
6BISExISzMx/jxwAdIASEhIDEh8gAxISAY+PAAD///+dgM4SEhISEgCd9gASEgMBGxI0LRIT
gI8DAH9Xj2SPjhISEun//xKDj4+PjwIKIg==

-- 
Eduardo Bustamante
https://dualbus.me/

Re: cygheap base mismatch detected

[Eduardo Bustamante]

On Thu, Jun 15, 2017 at 11:30 AM, Jon Morris  wrote:
> Hi,
>
> Just tried to submit a bug, but bashbug command failed, so here is the 
> problem text.
>
> Thanks,
>
> Jon

Please report this to the Cygwin folks. This is not a bash issue.

Re: cygheap base mismatch detected

[Eduardo Bustamante]

On Thu, Jun 15, 2017 at 1:19 PM, Eduardo Bustamante <dual...@gmail.com> wrote:
[..]
> Please report this to the Cygwin folks. This is not a bash issue.

Err, not the Cygwin folks. You seem to be using Cmder, so ask them.

Re: Why does 'connect' take so long (sometimes) and can't be interrupted?

[Eduardo Bustamante]

On Thu, Jun 15, 2017 at 10:36 AM,   wrote:
[...]
> Description:
> This is a little complicated and I can't give you full details on how 
> to
> replicate it, since I don't fully understand it myself.  But under 
> certain
> circumstances, the following line takes a very long time to execute:
>
> exec 5<>/dev/tcp/localhost/12345

Attach to the hanged process with gdb, print a backtrace and reply
back, so that we can see where it's stuck.

Re: Buffer corruption when the terminal is resized.

[Eduardo Bustamante]

On Sat, Jun 10, 2017 at 06:49:13PM +0200, Paul Peet wrote:
> declare -- PS1="\\[\\e]0;\\u@\\h:
> \\w\\a\\]\${debian_chroot:+(\$debian_chroot)}\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$
> "
[...]
> > Bash relies on \[ and \] to determine how much space is occupied by the
> > prompt when it is to be redrawn, so in this case it thinks the prompt is 2
> > columns wider than it actually is.

George already said it. There are two types of characters inside the
prompt string, visible and invisible. Color sequences are of the
invisible kind (these have an effect on the terminal, but do not occupy
any space on the line). You must wrap invisible character sequences with
\[ and \], otherwise Readline's calculation to figure out the physical
lenght of your prompt string will be off, and will cause the effect that
you're experiencing.

Try with:

#  v- this is an invisible sequence.
PS1='\[\e]0;\]\u@\h:\w\a\$...'
    # ^  ^

instead.

-- 
Eduardo Bustamante
https://dualbus.me/