Re: pwd and prompt don't update after deleting current working directory

[Eduardo Bustamante]

On Thu, Jul 11, 2024 at 7:32 PM David Hedlund  wrote:
(...)

> I understand. So the feature request should be an option "-b" (for
> bounce out of the directory when deleted) for example?
>

It'd be helpful to know about the use cases for such feature though.

My assumptions:

- This would only be useful in interactive sessions. Portable scripts would
not have access to this feature, and so in these cases the script writer
must explicitly consider the case where $PWD is unlinked while the process
is running. Or decide that it's not worth handling.

- In an interactive session: What are the conditions that lead to a
directory being removed without the user's knowledge?

- Also, what's wrong with letting a user deal with this by issuing `cd ..`?
Surely, this doesn't happen frequently enough that it merits increasing the
complexity of Bash to handle it automatically.

Re: pwd and prompt don't update after deleting current working directory

[Eduardo Bustamante]

On Thu, Jul 11, 2024 at 7:20 PM David  wrote:
(...)

> Hi, I disagree, and I think if you understand better why this occurs, you
> will understand why knowledgable users will disagree, and you will
> change your opinion.
>

I concur. The requested feature changes behavior in a
backwards-incompatible way, and thus it is guaranteed to break existing
scripts. The semantics of file removal in POSIX systems is well-defined,
and users of Bash and other POSIX compliant shells should make an effort to
learn about them, instead of changing every system to match their mental
model.

Re: String replacement drops leading '-e' if replacing char is a space

[Eduardo Bustamante]

>
> Description:
>
> If a string starts with '-e' the replacement operators ${x//,/ } and ${x/,
> /} drop the '-e'.
> The behaviour seems to be very specific: the string must start with '-e'
> and the replacing character has to be a space.
>
> Repeat-By:
>
> x='-e,b,c'
> echo ${x//,/ }
> b c
> echo ${x/,/ }
> b,c
>

The echo command is consuming the '-e', as it is a flag.  Instead, try
using:

  printf '%s\n' "${x/,/ }"

Re: git amend commit with backticks on cli causes tty to crash

[Eduardo Bustamante]

On Fri, Jul 21, 2023 at 9:14 AM Dale R. Worley  wrote:
> (...)
> Also, you don't state explicitly what you think the error is.  I assume
> you mean that "Press [ctrl-d] again and tab (tty 5) crashes." should not
> be happening.
>
> But it looks to me like you're sending ctrl-d into a shell.  That, of
> course, is EOF, and usually tells the shell to exit.  If it's a login
> shell, the whole login session ends.

One thing that comes to mind is that there was a behavior change in 5.2
around how EOF is handled while the parser is looking for a matching quote.

For example, with Bash 5.1 (note:  indicates pressing the Return
key in the prompt)

bash-5.1# echo '
> 
bash: unexpected EOF while looking for matching `''
bash: syntax error: unexpected end of file
bash-5.1#
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-musl)


And Bash 5.2

bash-5.2#
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-musl)
bash-5.2# echo '
> 
bash: unexpected EOF while looking for matching `''
> 
exit


In 5.1, when you input a command that has an unpaired quote and then input
Ctrl-d you get a syntax error and return to the primary prompt.
When you do the same in 5.2, the first Ctrl-d will show an unexpected EOF
message but you will remain in the secondary prompt. A second Ctrl-d will
then cause Bash to exit.

This change was discussed in
https://mail.gnu.org/archive/html/bug-bash/2023-02/msg00145.html

Re: With DEBUG trap, resizing window crashes script

[Eduardo Bustamante]

On Wed, May 10, 2023 at 1:03 PM Wiley Young  wrote:
> (...)
>   The script is set up to enable the DEBUG trap and prompt. When the first
> user prompt appears, in this case `set -x` although xtrace was enabled at
> the crashbang, if I resize the window then press enter, the script dies and
> displays that a SIGWINCH was received.

It seems to me that Bash is behaving as expected. When the terminal
resizes, a SIGWINCH signal (Window resize signal) is sent to the
foreground process. You seem to have defined a trap for this signal,
and the action of that trap is to kill the current shell with SIGINT
(2).

> +++./find-and-scan-shell-scripts-sh:1:_debug_prompt: trap SIGWINCH
> +++./find-and-scan-shell-scripts-sh:1:_debug_prompt: kill -s 2 96527

If you wish for the current shell to continue running after a terminal
resize, then set the signal disposition for SIGWINCH to ignore.

Re: bottom of ${BASH_LINENO[*]} stack is always '0'

[Eduardo Bustamante]

On Tue, Feb 21, 2023 at 2:58 PM bill-auger  wrote:
>
> the bottom of the ${BASH_LINENO[*]} stack is always '0'; and the
> array never contains the line number of the actual call site, as
> ${LINENO} does - is that expected behavior?
>
> im not sure if this is a bug or not - it seems like a bug to me
> though - the '0' value is meaningless and useless, yes?

It may make more sense if you consider that BASH_LINENO is meant to
supplement the FUNCNAME and BASH_SOURCE arrays. It doesn't seem quite
useful on its own.

>From the manual:

| BASH_LINENO
|An array variable whose members are the line numbers in
source files where each corresponding member of FUNCNAME was invoked.
${BASH_LINENO[$i]} is the line number in the
|source  file  (${BASH_SOURCE[$i+1]}) where ${FUNCNAME[$i]}
was called (or ${BASH_LINENO[$i-1]} if referenced within another shell
function).  Use LINENO to obtain the cur‐
|rent line number.

| BASH_SOURCE
|An  array  variable  whose  members  are  the source
filenames where the corresponding shell function names in the FUNCNAME
array variable are defined.  The shell function
|${FUNCNAME[$i]} is defined in the file ${BASH_SOURCE[$i]} and
called from ${BASH_SOURCE[$i+1]}.

| FUNCNAME
|An array variable containing the names of all shell functions
currently in the execution call stack.  The element with index 0 is
the name of any currently-executing shell
|function.  The bottom-most element (the one with the highest
index) is "main".  This variable exists only when a shell function is
executing.  Assignments to FUNCNAME have
|no effect.  If FUNCNAME is unset, it loses its special
properties, even if it is subsequently reset.
|
|This variable can be used with BASH_LINENO and BASH_SOURCE.
Each element of FUNCNAME has corresponding elements in BASH_LINENO and
BASH_SOURCE to describe the call stack.
|For instance, ${FUNCNAME[$i]} was called from the file
${BASH_SOURCE[$i+1]} at line number ${BASH_LINENO[$i]}.  The caller
builtin displays the current  call  stack  using
|this information.

With a call stack that looks like this

f2 <- called by -- f1

You'd expect to see the following: FUNCNAME=([0]="f2" [1]="f1" [2]="main")

Notice that 'main' is the bottom of the stack. This is not an actual
function, but a name given to the main shell script, i.e. the script
that sources and/or calls other functions. As 'main'
does not correspond to an actual line on a script, I think it's
appropriate for its line number to be 0. It might as well be -1, '',
or any other value that does not map to a real piece of code.

My guess as to why 'main' is in FUNCNAME -- and therefore its "line
number" in BASH_LINENO -- is that it allows you to determine which
shell script is the main script. That'd be 'foo' in the following
example:

$ cat foo
source bar

$ cat bar
f() {
  declare -p BASH_SOURCE FUNCNAME BASH_LINENO
}
f

$ bash foo
declare -a BASH_SOURCE=([0]="bar" [1]="bar" [2]="foo")
declare -a FUNCNAME=([0]="f" [1]="source" [2]="main")
declare -a BASH_LINENO=([0]="4" [1]="1" [2]="0")

Re: Performances comparission between 5.1 and 5.2.

[Eduardo Bustamante]

On Mon, Aug 15, 2022 at 10:09 AM Greg Wooledge  wrote:

> On Mon, Aug 15, 2022 at 07:05:49PM +0200, felix wrote:
> > Description:
> >   Trying some script under 5.2 beta, rc1 and rc2, I was surprised by
> execution time.
>
> Pre-release versions of bash are built with extra debugging stuff, and
> will not perform like full-release versions.
>

Chet explains this in
https://lists.gnu.org/archive/html/bug-bash/2014-01/msg00126.html

Re: current bash.git.devel segfaults on my code

[Eduardo Bustamante]

On Wed, Oct 20, 2021 at 3:46 AM Alex fxmbsw7 Ratchev  wrote:
>
> it betteted up, it still segfaults without valgrind but valgrind dorsnt
> show so many entries anymore
> there are 3 valgrind outputs, one without -- two with ine --arg ( the
> valgrind supported .. ) and three the two --opts
>
> the first two i can paste, the third due to being long is attached

The Valgrind reports that you shared do not exhibit the segmentation
fault crash, so they aren't too helpful in diagnosing the crash.

Re: $PPID behave differently in 5.1 and 4.3

[Eduardo Bustamante]

On Sun, May 16, 2021 at 1:38 AM leodream  wrote:
>
> I created 2 scripts like below
> 
>
> Running the test1.sh with bash 5.1 will have different PPID printed by the
> last test2.sh call when it is executed in sub-shell.
> For bash 4.3, the script will output consistent PPID.
> 
>
>
> It looks like something had been changed regarding the sub-shell execution
> in later Bash versions?

Yes. See the following entries in the 5.1 changelog
(https://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES-5.1?h=88bdb448b40b81a8dc1b8c2682bb5bb968d8213b#n134):

$ grep optimize CHANGES-5.1
c. Bash attempts to optimize away forks in the last command in a function body
b. Bash attempts to optimize the number of times it forks when executing

What you're seeing is that bash notices that it can optimize the
function call by avoiding a fork when calling "test2.sh" the third
time, thus the parent PID is different. This is done by the
`optimize_shell_function` in builtins/evalstring.c.


By the way, in the future, avoid sending scripts as screenshots and
instead just send them as plain text.  It makes it more difficult for
us to help you because now we have to transcribe your code from a
picture and hope that we didn't make any mistakes along the way.

Re: Latest devel branch push

[Eduardo Bustamante]

On Sat, May 15, 2021 at 4:54 AM Alex fxmbsw7 Ratchev  wrote:
>
> may i ask frankly for the git cmd to get it

You can find the instructions on how to clone the repository in the
Savannah portal: https://savannah.gnu.org/git/?group=bash

i.e.

git clone https://git.savannah.gnu.org/git/bash.git

Re: incorrect character handling

[Eduardo Bustamante]

On Tue, Mar 30, 2021 at 1:38 PM by.sm--- via Bug reports for the GNU
Bourne Again SHell  wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: darwin18.7.0
> Compiler: clang
> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
> uname output: Darwin Mac 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 
> 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
> Machine Type: x86_64-apple-darwin18.7.0
>
> Bash Version: 5.1
> Patch Level: 4
> Release Status: release
>
> Description:
> Bash (zsh/ash/etc) has incorrect character handling, when spec 
> symbols use in another program and work with stdout. Problem with command 
> "!!", "!", "$", etc.
>
> Example: use standart output to console by python3:
> python3 -c "print('ls')"
>
> It's return ls to stdout. But if i print something like:
> python3 -c "print('wow, it\'s working !!)"
>
> bash will process "!!" like a command and substitute the previous command.

Yes, this is a feature! It's called "history substitution" and it's
enabled by default on interactive shells. You can read more about it
in the bash manual. If you don't need this behavior, you can turn it
off with: set +H

Re: how does ssh cause this loop to preterminate?

[Eduardo Bustamante]

On Wed, Mar 24, 2021 at 2:22 PM gregrwm  wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
> uname output: Linux ginger 4.18.0-240.15.1.el8_3.x86_64 #1 SMP Mon Mar 1
> 17:16:16 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 0
> Release Status: release
>
> Description:
> [Detailed description of the problem, suggestion, or complaint.]
>
> Oddly, somehow, invoking ssh in a loop causes the loop to preterminate.
> Why?

Read https://mywiki.wooledge.org/BashFAQ/089, it should explain what
you're seeing here.

The summary is that SSH is reading from the same file descriptor as
"read". Use '-n' (or redirect SSH's stdin from /dev/null) to prevent
this.

Re: the bugs on simplificied code didnt appear im sorry check up the old paste or let it be

[Eduardo Bustamante]

On Tue, Feb 2, 2021 at 12:52 PM Alex fxmbsw7 Ratchev  wrote:
>
> bash-5.1# n=1 bash ../ixz/paster desc 0 1 2 3
> ++ paste BEGIN ++

Could you at least use a standard archive format to send these, and
not whatever this format is? I doubt you'll get much help when the
first step is to piece together a bunch of scripts encoded in a
strange paste format.

You can upload to wherever and just link it here.

Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"

[Eduardo Bustamante]

On Thu, Jan 21, 2021 at 2:07 PM Mathias Steiger
 wrote:
>
>
> As such bugs are likely related to buffer issues, maybe even in
> underlying APIs, and since they only surface after very lengthy
> mysterious sequences of commands - often just on single specific system
> installations - I wouldn't know how you can reproduce this in a test.
>
> Maybe you have specific testing frameworks for this, that would reduce
> the whole script to more basic components and which schematically remove
> or add complexity until the nature of the bug becomes more apparent?
>
> This seems to call for a specialist who is able to follow the problem
> into a far lower level of abstraction.
>
> As it stands now, I don't see how there is no way how this kind of
> execution can make any sense from a scripting POV.
>
> Of course in a giant script, all sorts of random things might happen.
> But this is not one of them.

You could run the script through "strace" or a similar command to see
what's writing that output and when. We could use that log output to
confirm that it is indeed Bash that is writing this out-of-order and
to a file descriptor that it shouldn't.

Greg pointed out earlier that the construct you're trying to use
doesn't work well when the shell is not Bash. Are you 100% confident
that it is /bin/bash that is running the script and not /bin/sh (and
thus maybe something like Dash?). And keep in mind that even Bash
running as /bin/sh is not quite the same as Bash running as /bin/bash.

Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"

[Eduardo Bustamante]

On Thu, Jan 21, 2021 at 1:32 PM Eduardo Bustamante  wrote:
>
> On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
>  wrote:
> >
> >
> > No.
> >
> > If you read the the rest of the bug report, it might become clearer to you.
> >
> >
> > Suppose I wrote a simple script:
> >
> >  {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> > "no"; fi } > output
>
> Did you mean:
>   echo "27ac5e2f757302" &> /dev/null;
>
> Instead?
>
> `>&` is not the same as `&>`

Actually, don't mind me. I'm wrong. I should've checked the manual first.

Sorry about the noise.

Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"

[Eduardo Bustamante]

On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
 wrote:
>
>
> No.
>
> If you read the the rest of the bug report, it might become clearer to you.
>
>
> Suppose I wrote a simple script:
>
>  {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> "no"; fi } > output

Did you mean:
  echo "27ac5e2f757302" &> /dev/null;

Instead?

`>&` is not the same as `&>`

Re: echo $'\0' >a does not write the nul byte

[Eduardo Bustamante]

On Sun, Jan 17, 2021 at 12:05 PM  wrote:
> (...)
> The nul byte is not echoed by $'\0'.

This is expected. Bash uses NUL-byte terminated character sequences to
store strings, so it can't actually store NUL bytes themselves.

$'\0'  is the same as '' (i.e. an empty string).

If you want to output an actual NUL byte, try using:

printf '\0'

Instead

Re: Bash Reference Mamual

[Eduardo Bustamante]

On Sat, Oct 17, 2020 at 3:48 PM Craig H Maynard  wrote:

> Hi,
>
> In section 3.5.4 "Command Substitution", the following sentence may have a
> typo:
>
> > The command substitution $(cat file) can be replaced by the equivalent
> but faster $(< file).
>
>
> My proposed change:
>
> > The command substitution $(cat file) can be replaced by the equivalent
> but faster <(cat file).
>
>
> If the manual is correct and I misunderstood something, please let me know.
>

Hi Craig,

<(cat file) and $(cat file) are not equivalent constructs. The former will
expand to a file name (e.g. "/dev/fd/63"), whereas the latter will expand
to the contents of the file.


In the case of   $(cat file)  and $(< file), they are equivalent, except
that in the second case there's no external command ("cat"), and instead
Bash reads the file and does the expansion itself.

Re: looking for consistent C-c trap behavior

[Eduardo Bustamante]

On Fri, Apr 17, 2020 at 1:09 PM Greg Wooledge  wrote:
>
> On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote:
> > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for
> > the GNU Bourne Again SHell  wrote:
> > >
> > > I've noticed that if I trap SIGINT in a bash script, the behavior when 
> > > encountering C-c depends on whether an external command (eg. 'sleep 100') 
> > > or a builtin command (like 'read -p') was encountered.
> > >
> > > I attach an example script which requires me to press C-c twice to 
> > > interrupt the builtin 'read -p' command, and it only works because I'm 
> > > restoring the trap via 'trap - SIGINT' the first time.
> > >
> > > My goal is to have C-c interrupt and use that exit code (130 most likely) 
> > > to exit with from script, regardless or whether or not the interrupted 
> > > command in the script was an internal or external one.
> > >
> > > How to do?
> >
> > I recommend reading: https://www.cons.org/cracauer/sigint.html
> >
> > The problem is that the signal is sent to the foreground process. When
> > "sleep" is running, it's the sleep command that receives the signal
> > and decides what to do with it. Not bash.
>
> That's not quite right.  When you press ^C in a terminal, SIGINT is sent
> to *all* of the processes in the "foreground" process group -- both sleep
> and bash, in the case you're discussing.

Oops. Apologies for giving out incorrect information.

And thank you for taking your time to explain it properly.

Re: looking for consistent C-c trap behavior

[Eduardo Bustamante]

On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for
the GNU Bourne Again SHell  wrote:
>
> I've noticed that if I trap SIGINT in a bash script, the behavior when 
> encountering C-c depends on whether an external command (eg. 'sleep 100') or 
> a builtin command (like 'read -p') was encountered.
>
> I attach an example script which requires me to press C-c twice to interrupt 
> the builtin 'read -p' command, and it only works because I'm restoring the 
> trap via 'trap - SIGINT' the first time.
>
> My goal is to have C-c interrupt and use that exit code (130 most likely) to 
> exit with from script, regardless or whether or not the interrupted command 
> in the script was an internal or external one.
>
> How to do?

I recommend reading: https://www.cons.org/cracauer/sigint.html

The problem is that the signal is sent to the foreground process. When
"sleep" is running, it's the sleep command that receives the signal
and decides what to do with it. Not bash.

Re: First lines of examples/startup-files/bashrc

[Eduardo Bustamante]

On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte  wrote:
(...)
> But, as far as I understand, a non-interactive bash doesn't read
> ~/.bashrc at all - so shouldn't we just omit them?

There are exceptions. One of them being SSH, see:
https://git.savannah.gnu.org/cgit/bash.git/tree/shell.c?h=ea31c00845c858098d232bd014bf27b5a63a668b#n1095

> /* If we were run by sshd or we think we were run by rshd, execute
> ~/.bashrc if we are a top-level shell. */

Re: Seg history

[Eduardo Bustamante]

On Tue, Oct 22, 2019 at 6:09 AM younes berramdane
 wrote:
>
> Hello,
> I have found a seg in the history of bash while I was doing a project for my 
> school,
> (Put fc -s at the last command of the history file [~/.sh_history] for bash 
> posix or [~/.bash_history] for bash then launch bash and execute fc -s again)

Hi Younes,

1) What version of bash are you using? (And did you compile it
yourself or are you using a specific software distribution?)
2) What do you mean by 'seg'? Do you mean a segmentation fault? If so,
can you generate a stack trace of the crash?

Re: Disable microsoft telemetry

[Eduardo Bustamante]

On Sun, Oct 20, 2019 at 4:55 AM Gerard E. Seibert  wrote:
>
> On Fri, 18 Oct 2019 18:17:27 +0330, Behrooz Amoozad stated:
> >I'm not sure if this even fits here, but it would be really nice if the
> >default bashrc included DOTNET_CLI_TELEMETRY_OPTOUT='true'.
> >Currently, After installing microsoft .net framework, it has telemetry
> >enabled by default and it works at least once upon installation. It
> >would be real nice if it didn't do that, anywhere, at all, not once.
> >And ONLY you have the power to make this right.
> >I don't know how many purists are left at gnu, I just hope there are
> >enough left making decisions for bash.
>
> I just read the
>  page,
> and it appears that the information collected is both configurable and
> used primarily to diagnose crashes. I don't find it overly intrusive
> myself, but each to his own I suppose.

In any case, this behavior has nothing to do with GNU Bash, and thus,
does not belong in this email list. Behrooz should raise this with
Microsoft.

Re: Wrong explanation of getopts

[Eduardo Bustamante]

On Sun, Sep 15, 2019 at 12:58 PM Roland Illig  wrote:
>
> The help text of getopts says:
>
> >   Getopts normally parses the positional parameters ($0 - $9), but if
> >   more arguments are given, they are parsed instead.
(...)
> The "instead" in "they are parsed instead" is totally wrong. $1 to $9
> are always parsed, no matter if there are more than 10 positional
> parameters or not.

It's not wrong.

> $ getopts
> getopts: usage: getopts optstring name [arg]

It's referring to the fact that you can explicitly pass a set of
parameters to `getopts' (i.e. the `[arg]' part), instead of it using
the script's positional parameters (i.e. $@).

Re: Incorrect passing of argc argv with multiple redirects

[Eduardo Bustamante]

On Tue, Jul 30, 2019 at 10:35 AM Morgan McClure
 wrote:
(...)
> ./a.out foo > /dev/null 2&>1; echo $?
> returns 3 NOT as expected

Are you 100% certain the `2&>1` redirection means what you think it
means? (hint: I recommend reading the "Redirecting Standard Output and
Standard Error" section of the bash manual, check if the leading `2`
is valid there).

Re: alias problem -- conflict found

[Eduardo Bustamante]

Can we please STOP this thread? What is the point? Linda will never
change her mind. You all are just wasting time and electricity.

(and spamming the mailing list with this non-sense).

Re: building bash 5.x problems+coredumps

[Eduardo Bustamante]

On Mon, Jul 8, 2019 at 3:44 PM L A Walsh  wrote:
>
> This hasn't worked for me yet, that I remember.  Some of itt may be in some
> library I'm linking, but not sure what might be causing the problem.

Can you provide more information about your environment?

- Compiler & version version
- "configure" flags
- Operating system & version
- libc & version
- stack trace for the core dump

Re: Using Source within Binary Shell Scripts

[Eduardo Bustamante]

On Wed, Mar 27, 2019 at 8:17 AM Jason Hall  wrote:
(...)
> The point is, their is a legitimate use for sourcing Binary Shell
> Scripts (...)

Is it really a legitimate use? If you're doing it for "security" (by
obscurity I guess?), it's easy to defeat.

> and BASH as is, won't let you do this.  Maybe not allow it by
> default but have a parameter to ignore the file check to see if it is
> binary.

How would that work though?

Re: General Associative Array problem -- Was: UUID as Array Keys strangely not possible

[Eduardo Bustamante]

On Fri, Feb 22, 2019 at 3:24 AM Robert White  wrote:
(...)
> tail --lines=+3 /proc/partitions | grep -v ram |
> while read -a RECORD
> do
(...)
>  eval [${INLINE[UUID]}]=boo
(...)
> done
>
> echo " Keys: " "${![@]}" = "${[@]}"
> echo " Keys: " "${![@]}" = "${[@]}"
> echo " Keys: " "${![@]}" = "${[@]}"

The `while' loop executes in a subshell and you're not using
`lastpipe'. See: https://mywiki.wooledge.org/BashFAQ/024

As a general recommendation: when submitting bug reports, try to
simplify things as much as possible, e.g.:

* Replace the `blkid' command invokation with a `printf' (not everyone
has the same block devices, nor runs Linux)
* Replace `/proc/partitions' with a copy of its contents (again, not
everyone has the same files in their systems, makes it impossible to
reproduce what you're experiencing)
* Remove the  and  arrays, we only need a sample case to
understand what's going on, not three
* Remove the sed commands, you're going to be using static values
(`printf') anyways
* Does the `set -f' at the top of the file have any effect in the
outcome in this particular case? no? then remove it
* I think you get the idea.


Just to help you understand my perspective, this is what I see when I
try to troubleshoot your script (a bunch of errors), that doesn't
really help me help you:

dualbus@system76-pc:~$ shellcheck foo.sh

In foo.sh line 12:
function testfunc() {
^-- SC1009: The mentioned syntax error was in this function.
^-- SC1073: Couldn't parse this brace group. Fix
to allow more checks.


In foo.sh line 13:
   eval INFUNC=( $( blkid /dev/${RECORD[3]} -o export | sed -e 's;\\
   ^-- SC1036: '(' is invalid here. Did you forget to escape it?
   ^-- SC1056: Expected a '}'. If you have one, try a ; or
\n in front of it.
   ^-- SC1072: Missing '}'. Fix any mentioned problems and
try again.
   ^-- SC1098: Quote/escape special characters when using
eval, e.g. eval "a=(b)".

dualbus@system76-pc:~$ ./foo.sh
Trying /dev/nvme0n1
./foo.sh: line 14: blkid: command not found
sed: -e expression #1, char 4: unterminated `s' command
Trying: +=( []=boo )
./foo.sh: line 16: []=boo: bad array subscript
./foo.sh: line 26: blkid: command not found
sed: option requires an argument -- 'e'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
 suppress automatic printing of pattern space
  --debug
 annotate program execution
  -e script, --expression=script
 add the script to the commands to be executed
  -f script-file, --file=script-file
 add the contents of script-file to the commands to be executed
  --follow-symlinks
 follow symlinks when processing in place
  -i[SUFFIX], --in-place[=SUFFIX]
 edit files in place (makes backup if SUFFIX supplied)
  -l N, --line-length=N
 specify the desired line-wrap length for the `l' command
  --posix
 disable all GNU extensions.
  -E, -r, --regexp-extended
 use extended regular expressions in the script
 (for portability use POSIX -E).
  -s, --separate
 consider files as separate rather than as a single,
 continuous long stream.
  --sandbox
 operate in sandbox mode (disable e/r/w commands).
  -u, --unbuffered
 load minimal amounts of data from the input files and flush
 the output buffers more often
  -z, --null-data
 separate lines by NUL characters
  --help display this help and exit
  --version  output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret.  All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

GNU sed home page: .
General help using GNU software: .
./foo.sh: line 27: s;\(.*\)=;[\1]=;: command not found
INLINE Keys:  =
INFUNC Keys:  =

Trying /dev/nvme0n1p1
./foo.sh: line 14: blkid: command not found
sed: -e expression #1, char 4: unterminated `s' command
Trying: +=( []=boo )
./foo.sh: line 16: []=boo: bad array subscript
./foo.sh: line 26: blkid: command not found
sed: option requires an argument -- 'e'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

  -n, --quiet, --silent
 suppress automatic printing of pattern space
  --debug
 annotate program execution
  -e script, --expression=script
 add the script to the commands to be executed
  -f script-file, --file=script-file
 add the contents of script-file to the commands to be executed
  --follow-symlinks
 follow symlinks when processi

Re: bug: illegal function name?

[Eduardo Bustamante]

On Sun, Jan 20, 2019 at 11:05 AM Andrey Butirsky  wrote:
>
> Eduardo, the question is about inconsistent, error-prone implementation.
> Not about the workarounds.

What's the error prone part?

- Declare a function name
- Unset it with 'unset -f'

Re: bug: illegal function name?

[Eduardo Bustamante]

On Sun, Jan 20, 2019 at 10:46 AM Andrey Butirsky  wrote:
>
> I'm not quite understand what exactly is "intentional".

Accepting different sets of function names (when POSIX mode is either on/off).

> The problem is inconsistent behavior of unset '-f' flag for "normal" and
> "not-normal" function names (I'm not considering conflicting with
> variable names case).
> This is just confusing and makes the scripts error-prone, IMO.

How about this: "/Always/ use unset -f to unset functions". Also,
don't ignore the "variable names case", because that's an important
piece here.

Re: Sourcing a script from a pipe is not reliable

[Eduardo Bustamante]

On Wed, Jan 9, 2019 at 10:54 PM Jeremy  wrote:
(...)
> 3.2.57(1)-release (x86_64-apple-darwin15)
>
>
> This is on MacOS 10.11.6. If there is a better place for me to report this
> bug, please let me know.

Have you tried the latest version? Bash 5.0 was just released:
https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html

I don't think you'll be seeing any updates in the OS X provided
version of bash, so there's no point in even trying to back-port any
fixes to 3.2

Re: Probable recursion in particular alias

[Eduardo Bustamante]

On Wed, Jan 9, 2019 at 4:59 AM Ante Perić  wrote:
(...)
> Description:
> Having an alias of type:
> alias bug="\
>echo \"no output, 100% cpu\" \
>   "
> in .bashrc will give no output, will not complete, and it will peg the CPU to 
> 100%.

Can you share the output of (right after the interactive bash session
starts up):

alias; declare -f

Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 12:12 PM Eduardo A. Bustamante López
 wrote:
(...)
> 2. Performance impact
>
> The new RNG does more work, and thus, it is expected to have a performance
> impact when generating lots of random numbers. I tested 3 systems (2 amd64 
> and 1
> armhf) and include the results below.
>
>
> AMD Ryzen 7 2700X:
>
> | dualbus@system76-pc:~/src/gnu/bash$ (set -x; lscpu; for bash in /bin/bash 
> ./bash; do "$bash" ~/test-speed.sh; echo; done)
> | + lscpu
(...)

Oops, I forgot to attach the test-speed script, it's fairly simple:

| #!/bin/bash
|
| iterations=100
|
| TIMEFORMAT='time: %R'
|
| echo "iterations: $iterations"
| echo "BASH_VERSION: $BASH_VERSION"
|
| RANDOM=1
| time for ((i=0; i

Re: Identical function names in bash source code

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 11:38 AM Peng Yu  wrote:
>
> > What would you say the "suggested improvement" is here?
>
> This is implied. If it is agreed that identical function names are not
> good by the majority of bash developers, then what I found could be
> turned into an explicit suggestion.
>
> Since maybe there is a good reason, I don't want to pretend that I
> knew why it was designed in this way.
>
> So far I don't see a good reason. So I want to confirm it first.
>
> Or this problem has never been noted before (I don't think it is very
> likely, given bash has been been developed for a long time). Then, it
> worth a discussion.

What is the problem EXACTLY though? GNU Bash and GNU Readline are two
different code bases. Bash depends on Readline, and thus, includes the
code tree in a subfolder. It makes sense that there are similar
functions for similar functionality in two different code bases,
specially when the author/maintainer is the same person.

Re: Identical function names in bash source code

[Eduardo Bustamante]

On Sat, Jan 5, 2019 at 10:25 AM don fong  wrote:
>
> for my 2c, the post seems within the charter.
>
> quoting from the bug-bash info
> page:
>
> > This list distributes, to the active maintainers of BASH (the Bourne Again
> > SHell), bug reports and fixes for, and *suggestions for improvements in
> > BASH. *

What would you say the "suggested improvement" is here?

To me, it reads as a generic C programming question that just happens
to use the source tree of GNU bash / GNU readline as an example.

Re: [Help-bash] How to run tests/?

[Eduardo Bustamante]

On Tue, Jan 1, 2019 at 10:09 PM Eduardo Bustamante  wrote:
>
> On Tue, Jan 1, 2019 at 9:42 PM Eduardo Bustamante  wrote:
>
> > On Tue, Jan 1, 2019, 8:46 PM Peng Yu,  wrote:
> >>
> >> I got the following errors when I try tests/ in the bash source code.
> >> Is it because my sh is just bash? Since I don't have a bare sh, how to
> >> run tests/?
> (...)
>
> > Have you tried 'make test'?
>
> Err, I meant to send this to the list. It's right there in the makefile
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/Makefile.in?h=6870125961b85baa9628ce4c5fbbca94e8046656#n946

Argh. Apologies. OK, next time I'll use Mutt instead of Gmail :) Sorry
for the spam.

Re: Should [[ -v 1 ]] be supported?

[Eduardo Bustamante]

On Thu, Dec 27, 2018 at 9:45 PM Peng Yu  wrote:
(...)
> Yes and no. For a particular bash script, you can quantify which bash
> features are the most time-consuming.
(...)
> (...) But you can not profile all the
> bash scripts that have ever been written. Since there are only limited
> features in bash, in this case, a logical way to go is to at least
> profile each commonly used feature with minimal code (as just for and
> repetitive calling that features as I do) and understand its pros and
> cons.

Err, where did you get this profiling advice from? :) It's not great.

You're just picking arbitrary expressions from a script w/o
understanding how they contribute in terms of % of time spent by your
program, then assume that tuning that is going to produce
*significant* benefits. Furthermore, your testing/measuring is not
really systematic, so the numbers you get aren't really meaningful
(are they specific to your system? or to the way you compiled bash?
are you taking caching and system load into consideration?
variability? etc.)

> (...) A profiler is an overkill in this case.

A profiler is exactly what you need here. You should profile your
script and understand the stuff that actually matters for your goals.
Otherwise you're just chasing unimportant things.

Honestly, if you're not willing to provide more context as to why
these areas should be optimized, then I'm just wasting my time here.

Re: Should [[ -v 1 ]] be supported?

[Eduardo Bustamante]

On Thu, Dec 27, 2018 at 5:38 PM Peng Yu  wrote:
>
> > I don't believe that at all. The number of positional parameters is kept
> > anyway. It's not recalculated when you compare it to another number, so
> > it's just as fast as a simple comparison of two integers.
>
> Getting the number $# is slow.

How do you determine that? All I ever see in your emails is that you
run things in a loop, get the wall clock and then absolutely declare
that something is slow/fast. That doesn't seem very methodical /
scientific.

* What hardware are you using to test?
* What is the state of the system during your tests?
* Are you also measure variability between runs?
* Are you testing in different hardware architectures?
* Are you testing with different compilers and compiler flags?

Let's say you are doing all of the above. You found that this
particular operation is "slow".

How many times do you execute the operation? Is your program really
spending MOST of its time computing the number of positional
parameters, really? REALLY?

If so, what are you doing? Is it a common enough thing that most of
bash users are going to benefit from this change? No? Just you?


> There is no reason why bash has to be slow. Javascript was slow. But
> it has been optimized to be much faster than it was before.

You do realize that bash is a SPECIALIZED language, not a general
purpose language? This is a poor argument.

In general, I agree that we should look into areas to optimize. You
can see that Chet has been implementing some optimizations over the
years. But the effort should be invested in an area that benefits most
users, not just you trying to do high performance computing in bash.

Re: How to compile hashlib.c for testing?

[Eduardo Bustamante]

On Thu, Dec 27, 2018 at 5:15 PM Peng Yu  wrote:
(...)
> Since the main() function is already there, why there is not already
> an easy way to compile it? How do you do unit-testing then for the
> code?

This is very easy to figure out from the source code, right :)?

(Hint: there is no "unit" testing in bash)

Re: Should [[ -v 1 ]] be supported?

[Eduardo Bustamante]

On Thu, Dec 27, 2018 at 4:50 PM Peng Yu  wrote:
(...)
> What I meant in my original email is that I want something for testing
> if there is a command line argument (one or more, the exact number
> does not matter). $# gives more than that info, because it tells not
> only whether is any command line argument, but also how many. This
> could lead to slower performance if the goal is to just test if there
> is an argument.
>
> [[ -z ${1+s} ]] does something also more than necessary too, because
> it not only tests for whether $1 is set, it also replaced with a
> string "s". This also does more than just testing whether $1 is set.
>
> So both cases would be slower than [[ -v 1 ]] if it were supported.
>
> As of now, because (($#)) or [[ -z ${1+s} ]] are not consistently
> faster than the other, there is no way to write a program that is
> consistently fastest. To achieve this goal, one has to implement [[ -v
> 1 ]] or something similar that just test whether $1 but no more.

Out of curiosity: What kind of software are you writing in bash that
you invest so much time in shaving those extra micro-seconds?

a) If you're doing this for fun, then I think you might understand why
it might be counter-productive to bloat Bash for a use case that is
uncommon?
b) If you're building real-world applications in bash that require
that level of performance, can you share what these applications do on
a general level and why you chose bash as the run-time? When arguing
for a feature, I think that explaining the expected use cases make a
much better argument.



Also, why do you expect an unimplemented feature to be a better option
to achieve more performance than two implementations that are already
available and can benefit from some optimizations?

Re: write() not retried after EINTR in printf and echo

[Eduardo Bustamante]

On Tue, Dec 25, 2018 at 12:01 PM Bize Ma  wrote:
(...)
> But, probably, I should just not inform you of what others think given your
> upfront rejection to any (constructive) criticism.
(..)
> Do as you wish, we will still be able to form our own opinion about buggy
> code.

This is not constructive criticism at all. What if instead of
complaining you do something about it, like, fixing the problem (send
a patch)?

Chet doesn't owe you anything.

Re: Bash build issues in `devel' branch due to -Werror compiler flag

[Eduardo Bustamante]

On Mon, Dec 17, 2018 at 6:31 AM Chet Ramey  wrote:
(...)
> Good. This is the kind of feedback I want from enabling this option during
> the pre-release period. Thanks for taking the time.

Thank you!

Bash `devel' builds fine for me now.

Re: Memory continusely increase

[Eduardo Bustamante]

+ Adding Abhishek

Hi Chen and Abhishek, it seems you might work on the same team since
you sent the exact same bug report:

- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00059.html
- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00058.html
- http://lists.gnu.org/archive/html/bug-bash/2018-12/msg00057.html

On Wed, Dec 19, 2018 at 6:45 AM jake  wrote:
>
> Hi all,
>
> I did a test about run a bash scriplt never quit,but met a memory usage
> issue that cause used memory continuous increase.
> This issue was present in bash-3.2.x, bash-4.0.x, bash-4.1.x, bash-4.2.x,
> bash-4.3.x. However, This issue was disappeared in bash-4.4.0, I can't trace
> which patch fixed the issue or which new feature was introduced in
> bash-4.4.0.

These versions (3.2, 4.0, 4.1, 4.2 and 4.3) are fairly old. Any
particular reason you're not upgrading to 4.4 instead?

> Could someone help to tell me which part of changes in bash-4.4.0, that
> would be give me a direction backport code changes from bash-4.4 to
> bash-3.2.x and bash-4.3.x.

(...)

> while(true);do
>  while (true); do
>ls > /dev/null
>  done
> done

My guess is that it's a memory leak in subshell creation. You don't
need that subshell by the way, the following should work just fine:

while :; do
 ...
done

The parenthesis are not only not needed, but they add overhead because
a new subshell is created every time.


Anyways, looking at the changelog for 4.4, it looks like it's going to
be time consuming to find / backport this, since there are many memory
leaks that were fixed:

$ grep -i leak ./CHANGES-4.4
c.  Fixed several memory leaks.
a.  Fixed a memory leak when processing ${!var[@]}.
i.  Fixed a memory leak in the code that removes duplicate history entries.
b.  Fixed a memory leak in programmable completion.
i.  Fixed a memory leak when processing declare commands that perform compound
s.  Fixed a memory leak that occurred when interrupting brace expansions
dd. Fixed a memory leak when creating local array variables and assigning to
p.  Fixed a potential file descriptor leak when dup2() fails while performing a
i.  Some memory leaks caused by signals interrupting filename completion have


I'll try to go through some of these changes later today to see if
anything evident comes up. I still recommend just upgrading to 4.4 if
you can though. Running outdated versions is never fun.

Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Eduardo Bustamante]

On Sat, Dec 15, 2018 at 6:08 PM Ole Tange  wrote:
(...)
> But your comment actually emphasizes my point: We _will_ have users
> who are naive enough to use $RANDOM in ways you and I would not do,
> because we know it is unsafe.
>
> Let's make those usages a little safer.

You know no one is stopping you from submitting a patch to actually
fix the documentation right? (or maybe, you know, submitting an actual
working patch to change the random generator, not just drop some
irrelevant code snippet you got from Wikipedia).

> And then we simply wait for Shellshock to happen.

Also, comparing this to shellshock is a huge strawman. Please don't do
that :), we all know better than that.

Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Eduardo Bustamante]

On Mon, Dec 3, 2018 at 9:36 AM Greg Wooledge  wrote:
>
> On Mon, Dec 03, 2018 at 05:31:18PM +0100, Ole Tange wrote:
> > Luckily I did not just assume that Bash delivers high quality random
> > numbers, but I read the source code, and then found that the quality
> > was low. I do not think must users would do that.
>
> You're correct.  Most users would not have to read the source code to
> know that the built-in PRNG in bash (or in libc, or in basically ANY
> other standard thing) is of lower than cryptographic quality.
>
> Most users already KNOW this.

I have to echo this. If you are writing an application that requires
high quality random number, the onus is on YOU to ensure that you're
using quality sources and a good CSRNG. It would be a user mistake to
just use whatever the standard library of the run-time you're using
provides. Do we have to change C's rand() too? Or python's "random"
module? Or perl's "rand"? Or ruby's? (etc etc)


I do agree that adding a note in the manual to this effect would be nice though.

Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Eduardo Bustamante]

On Sun, Dec 2, 2018 at 3:14 PM Ole Tange  wrote:
(...)
> Git's use of SHA1 seems to be a prime example of what can go wrong:
> https://shattered.io/

What does a PRNG have to do with a hashing function?

> Can you elaborate on why you think it is a bad idea to change an
> insecure PRNG into a non-broken one?

I think you should elaborate on why you think the current one is
"broken", not the other way around; since you're the one that claiming
that is broken, but haven't really said why that is true.

IMO, Bash's PRNG is decent enough for what its intended use is. It's
definitely not meant to be used for cryptography. If I want a strong
random number, I can rely on OpenSSL or the /dev/urandom device.


Also, I don't really see how the code you sent generates a random number:

* How do you seed the initial state?
* How do you convert the 16-element array of 32-bit numbers to an
integer in the 0 - 32767 range?

People already expect $RANDOM to behave in a certain way, so you can't
really change that interface without breaking stuff. Whatever you use
to replace the brand() function should have the same interface.

Re: Indices of array variables are sometimes considered unset (or just display an error).

[Eduardo Bustamante]

On Mon, Nov 5, 2018 at 6:01 PM Great Big Dot  wrote:
(...)
> > [... A]ccessing the index list of multiple-element arrays
> > fails when you append the unset expansion. With single-element
> > arrays, it fails iff the element in question contains any special
> > characters or whitespace, and thinks the array is unset otherwise.
> > (Further testing shows that a value of the empty string also throws
> > an error.) Finally, empty arrays are also considered unset[...]
>
> Oops, just realized what's causing this. I guess it isn't necessarily a
> bug? Debatable, I guess.
>
> What's actually happening here is that the *indirection* expansion
> "${!foo}", and not the *indices* expansion "${!foo[@]}", is what is being
> preformed on something like "${!array[@]-}". Both expansions, while
> unrelated, happen to use the same syntax, with the exception that
> indirections apply to normal variables and index expansions apply to array
> variables. For some reason, adding on the "${foo-default}" expansion causes
> the former to be used instead of the latter. This can be seen here:

Sorry, I'm having a hard time following this email thread.

What is your ultimate goal or the actual problem you're trying to solve?

(BTW, I would recommend against trying to do three expansions in one.
It might be more terse, but it's hard to read and as you found out,
leads to weird behavior)

Re: [BUG] Bad call to dircolors in /etc/bash.bashrc on LMDE

[Eduardo Bustamante]

On Wed, Oct 31, 2018 at 9:52 PM Philip Hudson  wrote:
(...)
> Description:
> At line 44 of /etc/bash.bashrc the line
>
>eval $(dircolors)
>
> is incorrect: it errors if $SHELL is tcsh. All other calls correctly
> specify 'dircolors -b'.
>
> Note: Arises on Linux Mint Debian Edition 2. I have not been able to
> determine whether this report is more properly addressed to GNU, or
> downstream to Debian or Linux Mint. Apologies if it's not you.

The upstream bash package doesn't provide any system configuration
files. So you're right, it should go to the distro bug tracker.

Re: Use-After-Free in Bash

[Eduardo Bustamante]

On Tue, Oct 30, 2018 at 1:03 PM Corbin Souffrant
 wrote:
(...)
> I found a reproducible use-after-free in every version of Bash from
> 4.4-5.0beta, that could potentially be used to escape restricted mode. I
> say potentially, because I can get it to crash in restricted mode, but I
> haven't gone through the effort of attempting to heap spray to overwrite
> function pointers.

Disclaimer: I'm not a maintainer.

Did you check the `devel' branch in the git repository?

I don't think the restricted mode is really advertised as a powerful
security feature, so IMO you should be able to report it here. If
you're worried though, you can always email Chet Ramey directly.

Re: Auto-update program cache feature

[Eduardo Bustamante]

On Wed, Oct 3, 2018 at 11:20 PM Jeffrey Walton  wrote:
(...)
> How Bash achieves it is an implementation detail left to the experts.
> I made a few suggestions that don't seem to fit well. That's OK
> because Bash internals is not my area of expertise.

I think it's important to always consider the cost (in terms of
implementation complexity and maintenance) of a feature we request
from a free software program :)

> Architecturally each instance of Bash is an object could receive a
> "clear cache" message. How it is achieved does not matter to me. What
> is important is, the right thing is done to relieve users from the
> extra work for the common case.

This paragraph contradicts what you said earlier. You keep suggesting
that Bash should adopt this global message passing system where every
instance of the shell can broadcast messages to each other... that is
EXTREMELY complicated.

Anyways, I should've read the manual before replying to this email
thread. There's already a mechanism in place for what you want, it's
the `checkhash' shopt.

Re: Local Privilege Escalation

[Eduardo Bustamante]

On Wed, Sep 26, 2018 at 4:27 PM cjoke  wrote:
>
> Hi, is there a bounty bug program for Bash?

AFAIK, there isn't. If you found a security vulnerability in bash,
please make sure to disclose it privately to Chet
(chet.ra...@case.edu) instead of this public mailing list.

Re: [bug-bash] Which commit for a bug in 4.3.48 which is fixed in 4.4.23

[Eduardo Bustamante]

On Mon, Sep 24, 2018 at 4:09 AM Dr. Werner Fink  wrote:
(...)
> Reconstructed the attached patch ... seems to work

Out of curiosity, what problem are you trying to solve?

Re: Bash-5.0-alpha available

[Eduardo Bustamante]

On Wed, May 23, 2018 at 12:55 PM Chet Ramey  wrote:
>
> The first alpha release of bash-5.0 is now available with the URL
>
> ftp://ftp.cwru.edu/pub/bash/bash-5.0-alpha.tar.gz
>
> and from the bash-5.0-testing branch in the bash git repository
> (http://git.savannah.gnu.org/cgit/bash.git/log/?h=bash-5.0-testing).

Out of curiosity, when / how will bash 5.x become a stable release?

The main reason I ask is that I'd like to ensure that there's
reasonable fuzzing coverage of the parser, readline and other
easy-to-fuzz areas of bash before that happens.

Re: expand_prompt_string segmentation faults

[Eduardo Bustamante]

On Sat, Sep 15, 2018 at 8:15 PM Chet Ramey  wrote:
(...)
> Thanks for the report. They are the same problem.

Thanks Chet. Do you have a patch for the issue? I have a few other
cases but I'm not sure if they're all due to the same cause.

Re: Assignment of $* to a var removes spaces on unset IFS.

[Eduardo Bustamante]

On Mon, Aug 13, 2018 at 5:25 PM Robert Elz  wrote:
[...]
> What's more, reporting bugs in bash 4.3 is just a waste of everyone's time.
> Upgrade to (at least) the current released version, and use that instead.

Adding to this point:

* bash 4.3 was released 4 years ago (2014-02-26)
* bash 4.4 is the current release of bash (2016-09-15)
* bash 5.0 is in alpha state (2018-05-22)

I know that some stable Linux distributions might still be
distributing 4.3, but that just means that you have to report the bug
against these distros, not upstream.

Re: Number with sign is read as octal despite a leading 10#

[Eduardo Bustamante]

On Tue, Jul 10, 2018 at 1:57 PM, Isaac Marcos
 wrote:
> Chet Ramey () wrote:
[..]
> This is not a serious argument.
[...]
> I don't care. All other shells do this correctly. It makes you the only one
> wrong.
>
> This is not a serious discussion.

Can you keep the discussion civil? I don't get why you feel compelled
to qualify an argument from the main developer as "non serious".

What's your definition of "correct"? According to Chet, the definition
is the same as the ISO C standard. I'm not sure if there's a public
version of the ISO C standard document, but
http://c0x.coding-guidelines.com/6.4.4.1.html seems to be good enough.
The definition of an "integer constant" in that document does not
include a sign.

So, in that regard, Bash is behaving according to specification.

Re: announcing bashj

[Eduardo Bustamante]

Thank you for your response Philippe. I'm adding back the mailing lists so
that they can benefit from this response too.


On Tue, Jun 26, 2018 at 5:58 AM, pg  wrote:

>
>
>
> *Thank you, Eduardo, for these remarks... I tried to answer you questions
> - answers in black below. But anyway, may I suggest you to read the
> following links (wiki links), providing a better understanding of what, why
> & how ... ? *
>
>- 
> *http://fil.gonze.org/wikiPG/index.php/Project_bashj_:_a_bash_mutant_with_java_support
>
> <http://fil.gonze.org/wikiPG/index.php/Project_bashj_:_a_bash_mutant_with_java_support>*
>- *http://fil.gonze.org/wikiPG/index.php/Bashj_programming_guide
><http://fil.gonze.org/wikiPG/index.php/Bashj_programming_guide>*
>
>
> On 23/06/18 20:45, Eduardo Bustamante wrote:
>
> On Sat, Jun 23, 2018 at 12:08 PM, pg  
>  wrote:
> [...]
>
> Description: BASHJ - ANNOUNCE TO THE DEVELOPMENT TEAM OF BASH
>
> I am pleased to inform you about bashj - a bash 'mutant' with java
> support.
> This product opens numerous very interesting fields to bash developers.
>
> I have a few questions / comments:
>
> * Under which license / use terms are you releasing bashj? It doesn't
> seem to be free software, the source code does not seem to be
> available in the Sourceforge project, and I can't find any reference
> to the license in the links you shared.   FWIW, I don't have
> enough confidence to test bashj by just downloading a random JAR file
> from the internet and executing it in my computer. I would like to be
> able to inspect the source code and build it myself.
>
> *I am not expert in the choice of licences. I don't care much about that,
> and  when the project was created on sourceforge I chose LGPLv2.1.*
> *Not sure that it is the appropriate one for a mix of bash & java source
> code.*
> *I understand your prudence regarding the jar file.*
> *From version 0.995, the java sources will be available on source forge.*
> *However I want to mention that :*
>
>- *Sources are currently poorly documented*
>- *My coding style is far from the java standards ! Compact code is my
>priority, and I certainly do not approve standards leading to voluminous
>code.*
>- *At this time, I do not want/need source contributors. Remarks, bug
>reports and suggestions are welcome, but I keep driving the code for a
>while.*
>
> * The wiki page recommends creating the installation directory with
> 0777 permissions. That seems a bit too insecure? Why does it need
> world-wide write permissions? (i.e. "sudo mkdir -m=777 /var/lib/bashj/
>   # create the installation directory")
>
>
> *I changed these: *
>
>- *installation target directory is /opt/bashj/*
>- *permission at creation time is set to 0755*
>- *transient files live under /dev/shm/bashj/ *
>
> *But I am not expert in risk detection.*
>
> * What's the motivation behind bashj?  I'm having trouble
> understanding why one would like to use a mixture of Java and bash in
> the same program, when there are options like Jython and Groovy to run
> dynamic scripting languages in the JVM.   Are you using bashj for a
> particular application for which Groovy wasn't apt?
>
>
>
>
>
>
>
>
>
>
>
> *I use bashj for my own projects. Il appreciate the idea of getting access
> to my wide and venerable java personal package library, including servers
> (accessible using memory mapped files). All this from bash, and with an
> impressive speed. I used groovy and was not convinced. Between java and
> python, my preference (laziness?) goes to java. I would like to need no
> more than 2 technologies : java & bash is enough. And what I read about
> jython was not convincing anyway : too heavy. If there is no significant
> public interest for bashj, I will keep using it alone, and remove it from
> source forge. It would be sad, because my experience with it is really
> exciting! *
>
> * Since I haven't run the code (for reasons explained above): How do
> you handle things like the program's current working directory, the
> environment, subshells, controlling terminal, etc. when everything
> seems to run in the same JVM server process?
>
>
>
> *Try it and you'll see how it works. There are some limitations, but AFAIK
> no blocking issues. It is partly discussed in the links provided above. If
> you see significant problems, please let me know. *
>
>
> --
> --
> --
>
> *Philippe Gonze*
> Address: *Rue de la bruyère 12 / 1428 Lillois
> <https://maps.google.com/?q=Rue+de+la+bruy%C3%A8re+12+/+1428+Lillois&entry=gmail&source=g>
> / BE*
> Phone : *00.32.473580758*
> www.gonze.org
> --
> --
>

Re: announcing bashj

[Eduardo Bustamante]

On Sat, Jun 23, 2018 at 12:08 PM, pg  wrote:
[...]
> Description: BASHJ - ANNOUNCE TO THE DEVELOPMENT TEAM OF BASH
>
> I am pleased to inform you about bashj - a bash 'mutant' with java
> support.
> This product opens numerous very interesting fields to bash developers.

I have a few questions / comments:

* Under which license / use terms are you releasing bashj? It doesn't
seem to be free software, the source code does not seem to be
available in the Sourceforge project, and I can't find any reference
to the license in the links you shared.   FWIW, I don't have
enough confidence to test bashj by just downloading a random JAR file
from the internet and executing it in my computer. I would like to be
able to inspect the source code and build it myself.

* The wiki page recommends creating the installation directory with
0777 permissions. That seems a bit too insecure? Why does it need
world-wide write permissions? (i.e. "sudo mkdir -m=777 /var/lib/bashj/
  # create the installation directory")

* What's the motivation behind bashj?  I'm having trouble
understanding why one would like to use a mixture of Java and bash in
the same program, when there are options like Jython and Groovy to run
dynamic scripting languages in the JVM.   Are you using bashj for a
particular application for which Groovy wasn't apt?

* Since I haven't run the code (for reasons explained above): How do
you handle things like the program's current working directory, the
environment, subshells, controlling terminal, etc. when everything
seems to run in the same JVM server process?

Re: [PATCH] A terminating signal has to complete a bash process

[Eduardo Bustamante]

It's in commit 96b7e26874047647e85bd5c7e71a7f664174c2cc, in the
`devel' branch of the git repository.

On Mon, May 21, 2018 at 12:42 AM, Andrei Vagin  wrote:
> Hello Chet,
>
> Have you had a chance to try this patch? Let me know if you will have
> any questions.
>
> Thanks,
> Andrei
>
> On Thu, May 03, 2018 at 04:29:13PM -0400, Chet Ramey wrote:
>> On 5/1/18 7:55 PM, Andrei Vagin wrote:
>>
>> >> If it's not obvious, I'm trying to determine whether making this change
>> >> will add any more value than simply exiting (perhaps with a particular
>> >> exit status).
>> >
>> > It will add more value. Without this changes, we will not know whether a
>> > bach process crashed or exited. If it will not generate a core dump after
>> > a crash, the tools like abrtd, coredumpd, etc will not detect this crash
>> > and will not report about this abnormal behaviour.
>>
>> OK, we'll try it. I'll be interested to see if any core dumps created by
>> causing a SIGSEGV will overwrite any stack information from the `real'
>> fatal signal.
>>
>> Thanks for the patch.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>

Re: PDF documentation output not readable (3.2.6 GNU Parallel)

[Eduardo Bustamante]

El jue., may. 10, 2018 11:11 AM, Greg Wooledge 
escribió:

> [...]
> > from Section 3.2.6 GNU Parallel
>
> GNU parallel is a separate project from GNU bash.  You'll want to
> report the bug to the GNU parallel tracker, at
>  or whatever email
> equivalent they have.
>

FWIW, the Bash manual does have a GNU parallel section. Strange, but it is
there.

>

Re: bash shows an error message about unpaired quotes, but they are paired

[Eduardo Bustamante]

On Mon, Mar 26, 2018 at 1:54 PM,   wrote:
[...]
> run 'sed -i "6a\find /srv/cowrie/log/ -mtime +7 -name \'cowrie.*\' -delete" 
> cowrietest'

That's not how you escape single quotes within single quotes. Read:
https://mywiki.wooledge.org/Quotes#Types_of_quoting

The proper way would be: run 'sed -i "6a\find /srv/cowrie/log/ -mtime
+7 -name '\''cowrie.*'\''...

Re: ${parameter/pattern/string} behaviour changed

[Eduardo Bustamante]

On Fri, Mar 16, 2018 at 1:18 PM,   wrote:
[...]
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
> Command: x="a b c"; echo "'${x// /','}'"
> On old systems the output is:  'a','b','c'
> In this version the output is: 'a,b,c'
> This new behavior breaks some scripts.


Hm, 4.3 is almost 4 years old, so that's hardly "new" behavior.
Furthermore, this behavior changed as a result of a bug report, see:

- http://lists.gnu.org/archive/html/bug-bash/2012-02/msg00106.html
- http://lists.gnu.org/archive/html/bug-bash/2013-03/msg00100.html

Re: Strange/incorrect behavior of a fake executable file

[Eduardo Bustamante]

(I've added bug-bash again)

On Tue, Mar 13, 2018 at 11:32 PM, Vladimir Likic  wrote:
> Thanks for the quick response!

> Your are correct, "." was in PATH (my bad), an it's calling itself
> recursively. That went into a spiral and crashed the computer (literally).

> Why is bash actually executing the file without '!#' ?

[...]

On Tue, Mar 13, 2018 at 11:34 PM, Vladimir Likic  wrote:
> Sorry, meant why is bash executing the file without hash-bang '#!' ?

You can see the answer here:
http://git.savannah.gnu.org/cgit/bash.git/tree/execute_cmd.c?h=devel&id=bf5b8103d466fdbc3bfcdaa5e21a0d0c0dce7cba#n5608

Oversimplified explanation:

Bash performs the execve() system call on the executable file
(`junk'). If the system returns ENOEXEC (i.e. not an executable), bash
will then try to execute the file itself

Re: Strange/incorrect behavior of a fake executable file

[Eduardo Bustamante]

On Tue, Mar 13, 2018 at 7:24 PM, Vladimir Likic  wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
> -DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-7fckc0/bash-4.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
> -Wno-parentheses -Wno-format-security
> uname output: Linux sparky 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3
> (2018-03-02) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
>
> A strange/unexpected behavior when one creates a file with a single line
> that is identical to the name of the file, gives exec permissions and
> attempts to run the file.
>
> Repeat-By:
>
> $ echo junk > junk
> $ chmod +x junk
> $./junk
> --> this completely destroys my system

Uh, what do you mean by that? And how is this a bash bug?

A few points:

1) You do not provide a hash-bang (i.e. #!/bin/bash), which means that
/bin/sh will be used (
2) You are using Debian apparently. /bin/sh in Debian is dash, not bash
3) What's the value of PATH? (I'm guessing you have an empty entry or
'.' in there, and therefore, the script calls itself recursively).
It's not good practice to have the current working directory in your
PATH, so, fix that.

Re: Avoiding file-based constraints for tmp files (ws Re: [minor] umask 400 causes here-{doc,string} failure)

[Eduardo Bustamante]

On Mon, Mar 12, 2018 at 2:05 PM, L A Walsh  wrote:
[...]
> What would be the downside(s) of such an implementation?

There's code out there that relies on several properties of regular
files, one of them for example, that you can seek on them. I recommend
against any change to here documents and here strings that breaks this
expectation.

Re: Heap buffer overread in token_is_assignment

[Eduardo Bustamante]

On Tue, Feb 20, 2018 at 2:07 PM,   wrote:
>
>
>
>
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: afl-gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' 
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -fsanitize=address 
> -Wno-parentheses -Wno-format-security
> uname output: Linux jefeus-vm 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 
> (2017-12-23) i686 GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release

Hi Jeremy. I see that you're fuzzing against 4.4.19. I did a bunch of
fuzzing work last year (mainly in the parser code and readline), so
some of these issues might be fixed already in git. For example, I'm
not able to reproduce this one against the `devel' branch in the git
repository. My recommendation here would be to fuzz against the
`devel' branch directly.

Re: bug-bash

[Eduardo Bustamante]

On Thu, Feb 8, 2018 at 4:23 PM, Nolan <4030...@gmail.com> wrote:
> I have found a 'result' of a command that cannot be a feature.
>
> Enter command, command executes, prints exit at the prompt.
>
> Goes to next line in terminal showing the "#" prompt.
>
> A "whoami" says root.
>
> Is this known?
> Do you need screen captures of my terminal session?
>
> Nolan
>

What command are you running? Also run: type -a COMMAND_THAT_YOU_ARE_RUNNING

Most likely, you're running something that causes your shell to exit,
and if you logged in as root and then changed to your user, it
explains why you're left at a root owned shell.

Re: xmalloc crash

[Eduardo Bustamante]

On Mon, Jan 8, 2018 at 8:22 AM, Chet Ramey  wrote:
> On 1/6/18 2:40 PM, Eduardo A. Bustamante López wrote:
>
>> So the allocation fails, even if the system has enough memory to handle it.
>> Upon closer inspection:
>>
>> dualbus@ubuntu:~/src/gnu/bash/lib/malloc$ cat -n malloc.c | sed -n 
>> '777,781p'
>>777  /* Silently reject too-large requests. */
>>778  if (nunits >= NBUCKETS) {
>>779  abort();
>>780return ((PTR_T) NULL);
>>781  }
>
> I'm not sure which version of bash you're looking at, since no version with
> that check has ever had abort() there.

Derp. I added that abort() for debugging purposes and forgot to remove
it. Sorry about that.

Thank you for the explanation by the way!

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

[Eduardo Bustamante]

On Tue, Jan 2, 2018 at 3:05 PM, Nat!  wrote:
[...]
> Description:
> The documentation states, that /etc/bash.bashrc should not be read
> (rightfully so IMO) with
> --rcfile.

FWIW, there are two things going on here:

(1) /etc/bash.bashrc is actually disabled by default in the upstream
bash source code distribution and it's not documented:

$ grep SYS_BASHRC config-top.h
/* #define SYS_BASHRC "/etc/bash.bashrc" */

(2) The behavior you observe (SYS_BASHRC and bashrc_file both being
sourced) has been in place for a few years now (since bash 2.05 at
least), so I don't think it's a good idea to change this now in
upstream code, given that it'll potentially affect users that rely on
this to behave in a certain way for distros that enable SYS_BASHRC.

$ git blame shell.c | sed -n '1187,1198p'
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1187)   /* bash */
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1188)   if
(act_like_sh == 0 && no_rc == 0)
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1189) {
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1190) #ifdef SYS_BASHRC
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1191) #  if defined (__OPENNT)
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1192)
maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1193) #  else
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1194)
maybe_execute_file (SYS_BASHRC, 1);
bb70624e9 (Jari Aalto 2000-03-17 21:46:59 + 1195) #  endif
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1196) #endif
28ef6c316 (Jari Aalto 2001-04-06 19:14:31 + 1197)
maybe_execute_file (bashrc_file, 1);
^726f6388 (Jari Aalto 1996-08-26 18:22:31 + 1198) }

As you can see, the wording that you report is not present in the
upstream distribution, so this is likely a debian patch.

$ PAGER= man doc/bash.1 | grep -e '^[[:space:]]*--rcfile file' -A3
   --rcfile file
  Execute  commands  from file instead of the standard
personal initialization file ~/.bashrc if the shell is interac‐
  tive (see INVOCATION below).


IMO, the right thing to do here would be to ask the Debian package
maintainer to correct the wording to indicate that both
/etc/bash.bashrc AND the file provided by --bashrc are executed.
Important to note here also that SYS_BASHRC is a mechanism exposed for
sysadmins who want to ensure that a certain configuration is applied
system-wide, regardless of what the users of the system desire. If
it's a system you control, you can always re-compile bash or remove
the file.

See: https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152 for prior
discussion.

Re: Bash: sleep execution issue with bash loadable builtins

[Eduardo Bustamante]

On Mon, Dec 4, 2017 at 5:08 AM, Thiruvadi Rajaraman
 wrote:
> Hi Chester,
>
> Based on your review comments and suggestions about the earlier fixes,
> reworked on the fix with pselect()
> to block the signal.

FYI,

Chet pushed a few changes related to this in commits
564452a3ec9b73a53949325cc4acb94021d5235b and
03e8e2f9c842a95b9a180097a2769ec59b082c3b, of the `devel' branch. You
might want to review them.

Re: [PATCH] Fix hang if $OLDPWD points to inaccessible directory

[Eduardo Bustamante]

On Mon, Nov 27, 2017 at 6:00 PM, Mikulas Patocka  wrote:
[...]
> Will you commit my patch? - if you agree with it.

Hi Mikulas. Chet is the one and only bash maintainer, you'd have to
convince him.

As a bystander that happens to be interested in bash's development, I
agree with your points, but expressing my opinion is the most I can
do.

Re: umask builtin

[Eduardo Bustamante]

On Wed, Nov 8, 2017 at 10:06 AM, kalle  wrote:
[...]
>> From umask(1p):
>>   For a symbolic_mode value, the new value of the file mode creation mask
>>   shall be the logical complement of the file permission bits portion  of
>>   the file mode specified by the symbolic_mode string.
>
> This sentence is inacceptably complicate. Furthermore, it is not clear
> which symbolic mode string is meant at the end of the sentence, but I
> suppose it has been written by you to undermine the given facts.

Eh, what?

> Am 08.11.2017 um 15:01 schrieb Eduardo A. Bustamante López:
>> Hm, is there a umask program that does this?
>>
>> Looking at the shells I have installed, they all do pretty much the same:
[...]
>
> I did not question this...
>
> it's just not the easiest logic to have different logics.
> or is the different behavior made clear in some other documentation than
> 'man 1p umask'?

I linked the POSIX standard document in my reply. Here it is
again: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/umask.html

That is how the standard specifies the behavior of the umask builtin.
If your question
is "why is it shown in that way", then the answer is: "because that's
what the standard
says". If you're not happy with the standard, you can go and ask the
Austin Group
about it.

Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release

[Eduardo Bustamante]

On Tue, Nov 7, 2017 at 5:58 AM, Alex Nichols  wrote:
[...]
> In order to trigger the bug I executed the command *`*cat sploit.buf*`*
> where sploit.buf is a just over 2GB file of ‘A’ characters. When this
> command is executed the bash terminal crashes with the following error
> “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes
> (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error message
> appears to vary on different Linux distros. On Kali 2017.2 64 bit the error
> message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate
> 18446744071562067968 bytes (4296613888 bytes allocated)”.
[...]

This is a normal memory exhaustion problem. You are asking bash to allocate
over 2 GiB of heap memory, and your system is unable to provide that amount
of memory.

> This bug may present a potential security risk as a malicious user may be
> able to crash a users bash session by tricking them into executing a
> malicious bash script.
[...]

This is not a security issue. If you can trick a user into running this script,
why stop there? Why not instead encrypt the file system and hold it for
ransom? or delete it? Or steal credentials by uploading ~/.netrc, ~/.ssh/id_rsa,
~/.aws/credentials, ...

You will find this problem in any program that allocates memory dynamically.
Try allocating a >2 GiB in python, ruby, perl, php, awk, ...

Re: help complete: mention remove all AND restore all

[Eduardo Bustamante]

On Sun, Nov 5, 2017 at 7:01 PM, 積丹尼 Dan Jacobson  wrote:
> OK, please on
> $ help complete
> at "-r" please mention
> "To instead toggle on and off PROGRAMMABLE completion, use shopt -[su] 
> progcomp."
>
> Reason: there is very little chance the user could Google the right
> answer out of the forest of answers out there.

I googled "disable programmable completion bash" and the first result
is: 
,
which lists the shopt to disable it. The second result also mentions
it: 
.

The manual is not supposed to have direct answers to all the possible
questions the user might have. That would just make the manual larger
(it is huge already) and unreadable.

Re: New MILLISECONDS “special” variable?

[Eduardo Bustamante]

El mié., nov. 1, 2017 8:48 PM, Eduardo A. Bustamante López <
dual...@gmail.com> escribió:

> [...]
> /* FIXME: do better validation */
> static int parse_timeval (const char *s, struct timeval *tv) {
>   char *ds;
>   timerclear(tv);
>   tv->tv_sec = strtol(s, &ds, 10);
>   if (ds && *ds == '.') {
> tv->tv_usec = strtol(ds + 1, NULL, 10);
>   }
>   return 0;
> }
>
> int timer_builtin (WORD_LIST *list) {

  [...]

parse_timeval (s, &tv2);
>   timersub (&tv1, &tv2, &tv3);
>   snprintf (b2, 64, "%ld.%ld", tv3.tv_sec, tv3.tv_usec);
>   bind_variable (delta, b2, 0);
>
>   update_value:
>   snprintf (b1, 64, "%ld.%ld", tv1.tv_sec, tv1.tv_usec);
>   bind_variable (current, b1, 0);
>

Heh, this is embarassing. Evidently, that is not the right way of parsing a
timeval, or of storing it in a string (i.e. the tv_usec member).

But at least it still works as a demo of how to approach the problem with
loadable builtins.

>

Re: 'fc' outputing text of DEBUG trap

[Eduardo Bustamante]

On Fri, Oct 27, 2017 at 1:21 AM, Boruch Baum  wrote:
> In Debian, using Bash version 4.4, path level 12, I've set a DEBUG trap
> in my .bashrc and tried running the following command, with the
> following output resulting. The five lines between the command being run
> by fc and that command's output, is the text of the DEBUG trap.

Here's a short reproducer:

dualbus@ubuntu:~$ HISTFILE=/dev/null bash --norc --noprofile -O extdebug
bash-4.4$ trap ': it is a trap' DEBUG
bash-4.4$ echo hi
hi
bash-4.4$ history
1  trap ': it is a trap' DEBUG
2  echo hi
3  history
bash-4.4$ fc -e true 1 3
trap ': it is a trap' DEBUG
: it is a trap
echo hi
: it is a trap
hi
history
: it is a trap
1  trap ': it is a trap' DEBUG
2  echo hi
3  history
4  trap ': it is a trap' DEBUG
5  echo hi
6  history
bash-4.4$
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

Re: Simple sleep scripts causes SEGFAULT

[Eduardo Bustamante]

On Wed, Oct 25, 2017 at 11:21 PM, Alex Coffin  wrote:
[...]
> Description:
> Segmentation fault. I'm honestly not sure why. I was using batsh to
> make a simple script. When I ran it generated a segfault. The segmentation
> fault DOES NOT occur if "sleep" is replaced with "echo".
> I also ran it on "GNU bash, version 4.4.12(1)-release
> (x86_64-redhat-linux-gnu)" using codingground (
> https://www.tutorialspoint.com/execute_bash_online.php) the same issue
> occurred.
>
> Repeat-By:
> Run the following script (assuming you trust me lol):
> function sleep {
>   local dur
>   dur="$1"
>   # if replaced with "echo" no segfault.
>   sleep ${dur}s
> }
> "sleep" $((5))

You are running the `sleep` function recursively, therefore exhausting
the stack of the bash process. I believe you intended to do something
like this instead:

sleep() {
  command sleep "$.."
}

Re: Bash should reset OLDPWD upon login, *only*.

[Eduardo Bustamante]

On Tue, Oct 3, 2017 at 5:01 PM, L A Walsh  wrote:
[...]
Ah, because you can't protect against everything, you leave your system
> open with no passwords on the logins?  What's your system name again? :-)

Linda. This topic has no relation at all with the reported issue, and
we're doing a disservice to Mikulas and the community by continuing
down this path of argumentation. Please stop.

Re: Declared Var Dynamic Initialization = No Return Code Back?

[Eduardo Bustamante]

On Tue, Sep 12, 2017 at 5:04 PM, Adam Danischewski
 wrote:
[...]
> Declaring a variable doesn't seem risky enough to eat up the return code.
> Is there a reason for this? I doubt that it would break anything to change.
> It's a lot more intuitive and syntactically streamlined to check for
> missing packages/software at the initial declaration as a sanity check.

This topic has been discussed several times in the past. Please
review: https://lists.gnu.org/archive/html/bug-bash/2010-03/msg00010.html
and https://lists.gnu.org/archive/html/bug-bash/2010-03/msg00036.html
for an explanation.

Re: 'time' doesn't time subshells that exec

[Eduardo Bustamante]

On Sat, Sep 9, 2017 at 5:16 AM, Martijn Dekker  wrote:
> The 'time' reserved word seems to be unable to time subshells that run
> 'exec'. Is this intentional? (ksh93, mksh and zsh all do manage this.)

As far as I know, it is intentional. Read this thread which is about a
similar issue: https://lists.gnu.org/archive/html/bug-bash/2016-10/msg00062.html

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: 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: 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: cygheap base mismatch detected

[Eduardo Bustamante]

On Thu, Jun 15, 2017 at 1:19 PM, Eduardo Bustamante  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: 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: Patch for unicode in varnames...

[Eduardo Bustamante]

+#ifdef HANDLE_MULTIBYTE
+#define legal_variable_starter(wc) (iswalpha(wc) || (L'_' == wc))
+#define legal_variable_char(wc) (iswalnum(wc) || (L'_' == wc))
+#else
 #define legal_variable_starter(c) (ISALPHA(c) || (c == '_'))
 #define legal_variable_char(c) (ISALNUM(c) || c == '_')
+#endif
 
 /* Definitions used in subst.c and by the `read' builtin for field
splitting. */
diff --git a/subst.c b/subst.c
index 3093309f..3bd399dd 100644
--- a/subst.c
+++ b/subst.c
@@ -6717,6 +6717,7 @@ parameter_brace_expand_rhs (name, value, op, quoted, 
pflags, qdollaratp, hasdoll
   free (t);
 
   /* bash-4.4/5.0 */
+  /* XXX: Update */
   vname = name;
   if (*name == '!' &&
   (legal_variable_starter ((unsigned char)name[1]) || DIGIT (name[1]) || 
VALID_INDIR_PARAM (name[1])))
@@ -7070,6 +7071,7 @@ get_var_and_type (varname, value, ind, quoted, flags, 
varp, valp)
   SHELL_VAR *v;
   arrayind_t lind;
 
+  /* XXX: Update */
   want_indir = *varname == '!' &&
 (legal_variable_starter ((unsigned char)varname[1]) || DIGIT (varname[1])
|| VALID_INDIR_PARAM (varname[1]));
@@ -8217,6 +8219,7 @@ parameter_brace_expand (string, indexp, quoted, pflags, 
quoted_dollar_atp, conta
   sindex = *indexp;
   t_index = ++sindex;
   /* ${#var} doesn't have any of the other parameter expansions on it. */
+  /* XXX: Update */
   if (string[t_index] == '#' && legal_variable_starter (string[t_index+1]))
/* {{ */
 name = string_extract (string, &t_index, "}", SX_VARNAME);
   else
@@ -8330,6 +8333,7 @@ parameter_brace_expand (string, indexp, quoted, pflags, 
quoted_dollar_atp, conta
   /* Indirect expansion begins with a `!'.  A valid indirect expansion is
  either a variable name, one of the positional parameters or a special
  variable that expands to one of the positional parameters. */
+  /* XXX: Update */
   want_indir = *name == '!' &&
 (legal_variable_starter ((unsigned char)name[1]) || DIGIT (name[1])
|| VALID_INDIR_PARAM (name[1]));
@@ -8388,6 +8392,7 @@ parameter_brace_expand (string, indexp, quoted, pflags, 
quoted_dollar_atp, conta
 }
 
   /* Process ${!PREFIX*} expansion. */
+  /* XXX: Update */
   if (want_indir && string[sindex - 1] == RBRACE &&
   (string[sindex - 2] == '*' || string[sindex - 2] == '@') &&
   legal_variable_starter ((unsigned char) name[1]))
@@ -9213,6 +9218,7 @@ comsub:
   /* Find the variable in VARIABLE_LIST. */
   temp = (char *)NULL;
 
+  /* XXX: Update */
   for (t_index = zindex; (c = string[zindex]) && legal_variable_char (c); 
zindex++)
;
   temp1 = (zindex > t_index) ? substring (string, t_index, zindex) : (char 
*)NULL;
diff --git a/variables.c b/variables.c
index a08313d7..a41f1ba0 100644
--- a/variables.c
+++ b/variables.c
@@ -4409,6 +4409,7 @@ valid_exportstr (v)
   internal_error (_("%s has null exportstr"), v->name);
   return (0);
 }
+  /* XXX: Update */
   if (legal_variable_starter ((unsigned char)*s) == 0)
 {
   internal_error (_("invalid character %d in exportstr for %s"), *s, 
v->name);
@@ -4418,6 +4419,7 @@ valid_exportstr (v)
 {
   if (*s == '=')
break;
+  /* XXX: Update */
   if (legal_variable_char ((unsigned char)*s) == 0)
{
  internal_error (_("invalid character %d in exportstr for %s"), *s, 
v->name);


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

AddressSanitizer: heap-buffer-overflow in shell_expand_line

[Eduardo Bustamante]

0x564df0f98d17 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb7d17)
#20 0x564df10820f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
#21 0x564df0f63401 in run_one_command 
(/home/dualbus/src/gnu/bash-build/bash+0x82401)
#22 0x564df0f618da in main (/home/dualbus/src/gnu/bash-build/bash+0x808da)
#23 0x7f4f9ae362b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#24 0x564df0f60749 in _start (/home/dualbus/src/gnu/bash-build/bash+0x7f749)
0x60207ef9 is located 0 bytes to the right of 9-byte region 
[0x60207ef0,0x60207ef9)
allocated by thread T0 here:
#0 0x7f4f9b6a3d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x564df1070d95 in xmalloc 
(/home/dualbus/src/gnu/bash-build/bash+0x18fd95)
#2 0x564df0fe28d7 in string_extract_double_quoted 
(/home/dualbus/src/gnu/bash-build/bash+0x1018d7)
#3 0x564df10159e7 in expand_word_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1349e7)
#4 0x564df0ff44f3 in call_expand_word_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1134f3)
#5 0x564df0ff5458 in expand_word 
(/home/dualbus/src/gnu/bash-build/bash+0x114458)
#6 0x564df1056ed3 in shell_expand_line 
(/home/dualbus/src/gnu/bash-build/bash+0x175ed3)
#7 0x564df10dd30d in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fc30d)
#8 0x564df10ddaef in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fcaef)
#9 0x564df10dcee8 in _rl_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x1fbee8)
#10 0x564df10dc727 in readline_internal_char 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb727)
#11 0x564df10dc7b9 in readline_internal_charloop 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7b9)
#12 0x564df10dc7dd in readline_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7dd)
#13 0x564df10dbe93 in readline 
(/home/dualbus/src/gnu/bash-build/bash+0x1fae93)
#14 0x564df1097136 in edit_line 
(/home/dualbus/src/gnu/bash-build/bash+0x1b6136)
#15 0x564df1094aa4 in read_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0x1b3aa4)
#16 0x564df0faac89 in execute_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0xc9c89)
#17 0x564df0fac89f in execute_builtin_or_function 
(/home/dualbus/src/gnu/bash-build/bash+0xcb89f)
#18 0x564df0faa11f in execute_simple_command 
(/home/dualbus/src/gnu/bash-build/bash+0xc911f)
#19 0x564df0f97f42 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb6f42)
#20 0x564df0fa082e in execute_connection 
(/home/dualbus/src/gnu/bash-build/bash+0xbf82e)
#21 0x564df0f98d17 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb7d17)
#22 0x564df10820f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
#23 0x564df0f63401 in run_one_command 
(/home/dualbus/src/gnu/bash-build/bash+0x82401)
#24 0x564df0f618da in main (/home/dualbus/src/gnu/bash-build/bash+0x808da)
#25 0x7f4f9ae362b0 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+0x1023ef) in string_extract_double_quoted
Shadow bytes around the buggy address:
  0x0c047fff8f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8fa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8fb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8fc0: fa fa fa fa fa fa fa fa fa fa fd fa fa fa 03 fa
=>0x0c047fff8fd0: fa fa 00 06 fa fa 02 fa fa fa fd fd fa fa 00[01]
  0x0c047fff8fe0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff8ff0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9000: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9010: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9020: 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
==20379==ABORTING

INPUT
G+4AAEv///13gBqpoPkFBQUFBSQbG2OAEAUFBQUFJBVJSUlJSUlJSUlJSUlJSUlJSUlJSUlJ
SUlJ/yVBqLwkQkf5lgv8AOwA/yj/sLC0sLHTsLCwsACWfj4kGvYgQQZ8fe4kJDVTPCT0JADrl5eq
l5eXl5eXl5eXl5eXdJeXZECXl+vr6+uAfyIbG2OA+QUFBQUFJBsbY4AQBQUFBQUkfwUF
BQUFBQUFBQUFBQCTFAAkKAAbBQ==

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

AddressSanitizer: heap-buffer-overflow in rl_kill_text

[Eduardo Bustamante]

UVFRT5FRUVFRRkFQgQOBs4Exgo
OBs4ExgYKDgbGAAABgEnKGEdAgAbOBMVFeEVFRUVFRT5FQgQOBs4ExgoOBs4ExgmABs4ExgoOBs4
ExhlGAAABhgn9wAmYR0CABs4ExgoOBs4ExgQEAsQEDMQGzgTGEX3ABAAANwQIEUYZAAGABDbABAA
ABjEAj9ADjs=

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

AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

[Eduardo Bustamante]

_completion_matches 
(/home/dualbus/src/gnu/bash-build/bash+0x212aab)
#4 0x55b2ceb76a63 in rl_complete_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x216a63)
#5 0x55b2ceac7a94 in bash_brace_completion 
(/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_tilde_expand

[Eduardo Bustamante]

+0x202b0)
#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: heap-buffer-overflow in rl_delete

[Eduardo Bustamante]

dow 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
==1736==ABORTING

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

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

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

[Eduardo Bustamante]

On Tue, Jun 13, 2017 at 04:30:23PM -0400, Chet Ramey wrote:
[...]
> I can't reproduce it with asan or without on Mac OS X. I'll look around
> for a Linux system with asan to run it on.

All these inputs seem to trigger the same problem. You'll find the
stacktrace as reported by ASAN first, and then the corresponding input
base64 encoded.


==12445==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60d0c159 at pc 0x7f0b81373063 bp 0x7ffc11229040 sp 0x7ffc112287f0
READ of size 138 at 0x60d0c159 thread T0
#0 0x7f0b81373062  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
#1 0x55787f2df88b in _rl_find_prev_mbchar_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x25d88b)
#2 0x55787f2e035c in _rl_find_prev_mbchar 
(/home/dualbus/src/gnu/bash-build/bash+0x25e35c)
#3 0x55787f2aeca1 in expand_prompt 
(/home/dualbus/src/gnu/bash-build/bash+0x22cca1)
#4 0x55787f2ba190 in rl_message 
(/home/dualbus/src/gnu/bash-build/bash+0x238190)
#5 0x55787f2a8986 in rl_display_search 
(/home/dualbus/src/gnu/bash-build/bash+0x226986)
#6 0x55787f2adab7 in _rl_isearch_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x22bab7)
#7 0x55787f2adcae in rl_search_history 
(/home/dualbus/src/gnu/bash-build/bash+0x22bcae)
#8 0x55787f2a87ac in rl_reverse_search_history 
(/home/dualbus/src/gnu/bash-build/bash+0x2267ac)
#9 0x55787f27e30d in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fc30d)
#10 0x55787f27dee8 in _rl_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x1fbee8)
#11 0x55787f27d727 in readline_internal_char 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb727)
#12 0x55787f27d7b9 in readline_internal_charloop 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7b9)
#13 0x55787f27d7dd in readline_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7dd)
#14 0x55787f27ce93 in readline 
(/home/dualbus/src/gnu/bash-build/bash+0x1fae93)
#15 0x55787f238136 in edit_line 
(/home/dualbus/src/gnu/bash-build/bash+0x1b6136)
#16 0x55787f235aa4 in read_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0x1b3aa4)
#17 0x55787f14bc89 in execute_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0xc9c89)
#18 0x55787f14d89f in execute_builtin_or_function 
(/home/dualbus/src/gnu/bash-build/bash+0xcb89f)
#19 0x55787f14b11f in execute_simple_command 
(/home/dualbus/src/gnu/bash-build/bash+0xc911f)
#20 0x55787f138f42 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb6f42)
#21 0x55787f2230f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
#22 0x55787f104401 in run_one_command 
(/home/dualbus/src/gnu/bash-build/bash+0x82401)
#23 0x55787f1028da in main (/home/dualbus/src/gnu/bash-build/bash+0x808da)
#24 0x7f0b80b8b2b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#25 0x55787f101749 in _start (/home/dualbus/src/gnu/bash-build/bash+0x7f749)
0x60d0c159 is located 0 bytes to the right of 137-byte region 
[0x60d0c0d0,0x60d0c159)
allocated by thread T0 here:
#0 0x7f0b813f8d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x55787f211d95 in xmalloc 
(/home/dualbus/src/gnu/bash-build/bash+0x18fd95)
#2 0x55787f2ae574 in expand_prompt 
(/home/dualbus/src/gnu/bash-build/bash+0x22c574)
#3 0x55787f2ba190 in rl_message 
(/home/dualbus/src/gnu/bash-build/bash+0x238190)
#4 0x55787f2a8986 in rl_display_search 
(/home/dualbus/src/gnu/bash-build/bash+0x226986)
#5 0x55787f2adab7 in _rl_isearch_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x22bab7)
#6 0x55787f2adcae in rl_search_history 
(/home/dualbus/src/gnu/bash-build/bash+0x22bcae)
#7 0x55787f2a87ac in rl_reverse_search_history 
(/home/dualbus/src/gnu/bash-build/bash+0x2267ac)
#8 0x55787f27e30d in _rl_dispatch_subseq 
(/home/dualbus/src/gnu/bash-build/bash+0x1fc30d)
#9 0x55787f27dee8 in _rl_dispatch 
(/home/dualbus/src/gnu/bash-build/bash+0x1fbee8)
#10 0x55787f27d727 in readline_internal_char 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb727)
#11 0x55787f27d7b9 in readline_internal_charloop 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7b9)
#12 0x55787f27d7dd in readline_internal 
(/home/dualbus/src/gnu/bash-build/bash+0x1fb7dd)
#13 0x55787f27ce93 in readline 
(/home/dualbus/src/gnu/bash-build/bash+0x1fae93)
#14 0x55787f238136 in edit_line 
(/home/dualbus/src/gnu/bash-build/bash+0x1b6136)
#15 0x55787f235aa4 in read_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0x1b3aa4)
#16 0x55787f14bc89 in execute_builtin 
(/home/dualbus/src/gnu/bash-build/bash+0xc9c89)
#17 0x55787f14d89f in execute_builtin_or_function 
(/home/dualbus/src/gnu/bash-build/bash+0xcb89f)
#18 0x55787f14b11f in execute_simple_command 
(/home/dualbus/src/gnu/bash-build/bash+0xc911f)
#19 0x55787f138f42 in execute_command_internal 
(/home/dualbus/src/gnu/bash-build/bash+0xb6f42)
#20 0x55787f2230f4 in parse_and_execute 
(/home/dualbus/src/gnu/bash-build/bash+0x1a10f4)
   

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

[Eduardo Bustamante]

On Tue, Jun 13, 2017 at 3:30 PM, Chet Ramey  wrote:
[...]
> I can't reproduce it with asan or without on Mac OS X. I'll look around
> for a Linux system with asan to run it on.

I had to use these exact same environment variables, otherwise the out
of bounds read wouldn't happen. I'm not sure if it might depend on the
terminal size or another variable that might make this hard to
reproduce.

I'll try with a few more crashing inputs to see if I can find a better
test case. I should probably also start writing down my locale, glibc
version, TERM, compiler flags and other variables that might help in
the reproduction.

AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

[Eduardo Bustamante]

dline/readline.c:670
#19 0x558a216dee94 in readline (prompt=0x558a2177a000 "") at 
../../../bash/lib/readline/readline.c:374
#20 0x558a2169a137 in edit_line (p=0x558a2177a000 "", itext=0x0) at 
../../bash/builtins/../../bash/builtins/read.def:1095
---Type  to continue, or q  to quit---
#21 0x558a21697aa5 in read_builtin (list=0x0) at 
../../bash/builtins/../../bash/builtins/read.def:559
#22 0x558a215adc8a in execute_builtin (builtin=0x558a21696013 
, words=0x6020c630, flags=64, subshell=0)
at ../bash/execute_cmd.c:4609
#23 0x558a215af8a0 in execute_builtin_or_function (words=0x6020c630, 
builtin=0x558a21696013 , var=0x0, 
redirects=0x0, fds_to_close=0x6020c7d0, flags=64) at 
../bash/execute_cmd.c:5107
#24 0x558a215ad120 in execute_simple_command 
(simple_command=0x6030c4f0, pipe_in=-1, pipe_out=-1, async=0, 
fds_to_close=0x6020c7d0) at ../bash/execute_cmd.c:4395
#25 0x558a2159af43 in execute_command_internal (command=0x6030c520, 
asynchronous=0, pipe_in=-1, pipe_out=-1, 
fds_to_close=0x6020c7d0) at ../bash/execute_cmd.c:811
#26 0x558a216850f5 in parse_and_execute (string=0x6020c910 "read -e", 
from_file=0x558a21746120 "-c", flags=4)
at ../../bash/builtins/evalstring.c:430
#27 0x558a21566402 in run_one_command (command=0x7ffed8a03718 "read -e") at 
../bash/shell.c:1405
#28 0x558a215648db in main (argc=3, argv=0x7ffed8a018e8, 
env=0x7ffed8a01908) at ../bash/shell.c:718


(gdb) frame 6
#6  0x558a2174188c in _rl_find_prev_mbchar_internal (
string=0x60d0c0d0 
"(reverse-i-search)`=\3723\372\356SS輀)\027\374\027\374\027\374\027\374\377:P\356SS輀)\027\374\027\374\027\374\027\374\377:P\356SS輀)\027\374\027\374\027\374\027\374\377:P\356SS輀",
 '\276' , seed=85, 
find_non_zero=0) at ../../../bash/lib/readline/mbutil.c:162
162   length = strlen(string);


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

Re: Buffer corruption when the terminal is resized.

[Eduardo Bustamante]

On Sun, Jun 11, 2017 at 12:29:33AM +0200, Paul Peet wrote:
[...]
> Unfortunately, I am still getting the same behavior as before (This
> also happens with xterm for some reason.)

Please do consider that Readline has little knowledge about what has
been written to the terminal. That's the terminal's reponsability.

What Readline does is to write your prompt, and place the cursor right
beside the prompt. In both of your animations, the prompt seems to be
rendered fine, I can't really tell because the animation is a bit fast.

Does the same problem happen if you use a different shell? (zsh, mksh,
dash, ksh93).

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

Re: Multiline commands do not survive history -w/-r

[Eduardo Bustamante]

On Sun, Jun 11, 2017 at 07:00:11PM -0600, gaze...@xmission.com wrote:
[...]
> Bash Version: 4.3
> Patch Level: 48
> Release Status: release
> 
> Description:
>   Multiline commands (i.e., a command with embedded newlines) do not 
> survive
>   intact when written out to the history file and then reloaded.

Have you tried bash 4.4?

See: http://lists.gnu.org/archive/html/bug-bash/2015-12/msg00202.html

  dualbus@debian:~$ history -c
  dualbus@debian:~$ declare -p HISTFILE HISTTIMEFORMAT
  declare -- HISTFILE="/tmp/zzz"
  declare -- HISTTIMEFORMAT="%s"
  dualbus@debian:~$ echo 'a
  > b
  > c'
  a
  b
  c
  dualbus@debian:~$ history -w
  dualbus@debian:~$ history -c; history -r; HISTTIMEFORMAT= history
  1  declare -p HISTFILE HISTTIMEFORMAT
  2  echo 'a
  b
  c'
  3  history -w

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

Re: A background ssh can take over the tty from bash?

[Eduardo Bustamante]

On Mon, Jun 12, 2017 at 10:24:38AM +0800, Clark Wang wrote:
[...]
> I've checked the ssh process and it does not catch SIGTTIN and that's why
> I'm confused.

Even if that were the case, what makes you think this is a bash bug?

Bash is not responsible for misbehaving children.

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