Re: Bug: Bash forgets sourcefile and linenumber of read-in functions
On Mon, Mar 11, 2019 at 02:26:20PM -0700, L A Walsh wrote:
> How would that break compatibility?
The same way shellshock did. A function exported by a parent bash
process using format A could not be read by a child bash process expecting
format B.
Now, you may be thinking, "This makes no sense! The parent bash and
the child bash should be the same shell, using the same format!" And
most of the time, that's true. But sometimes the child environment
is different from the parent environment. For example, if someone has
a chrooted operating system(*) which is older/newer than the main OS,
there may be two different versions of bash between the outer and inner
environments. A function exported from the outer environment might not
be readable by the chrooted bash.
This happened in real life, to many people.
Also, the non-traditional environment variable names broke some
implementations of at(1) which expected the output of env(1) to be
readable by a shell. (Hint: it's not.)
I have no objection to bash adding the feature you're requesting,
although I think you may be the only person who actually cares about it.
I just want to make sure you're aware of the ramifications.
Personally I think a patch to allow exporting arrays would be of wider
interest, but I am not going to write that either.
(*) Or Docker container, etc. The specific case that I saw more than
once was in Debian, where one release of Debian adopted the FIRST set
of shellshock patches that used BASH_FUNC_funcname() as the variable
name, while another release of Debian adopted the SECOND set of
shellshock patches that used BASH_FUNC_funcname%% as the variable name.
People with Debian 7 chrooted inside Debian 8 (or vice versa) ran into
the problem that the two patched versions of bash were not compatible
with each other.
Observe:
ebase@ebase-fla:~$ cat /etc/debian_version
7.11
ebase@ebase-fla:~$ bash -c 'f() { :; }; export -f f; env | grep BASH_FUNC'
BASH_FUNC_f()=() { :
root@meglin2:~# cat /etc/debian_version
8.11
root@meglin2:~# bash -c 'f() { :; }; export -f f; env | grep BASH_FUNC'
BASH_FUNC_f%%=() { :
The same applied to anyone who compiled their own (patched) version of
bash on a system whose /bin/bash or /usr/bin/bash used a different set
of patches. A script running under #!/usr/local/bin/bash which exported
a function and then called a script running under #!/bin/bash might not
have the exported function working.
One Crash per Log-in Caused by: echo '' > >(echo)
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux vineyard.localdomain 4.20.14-200.fc29.x86_64 #1 SMP Tue Mar
5 19:55:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.4
Patch Level: 23
Release Status: release
Description:
Under the circumstances described below, the following command crashes Bash:
echo '' > >(echo)
Replacing '' with "", ' ', or " " has the same effect.
Replacing >(echo) with >( echo ) has the same effect (spaces added).
Please see the old bug titled "Fatal bug with redirection". It gives the
following command:
{ echo a >&3 ; } 3> >( echo b )
That command has the same effect, however, like the one I give first, it
only crashes Bash
*once* per login, a property not mentioned in the old bug's mailing thread.
Below, I give further details on how the bug is associated with log-ins.
Repeat-By:
#
# #
# Heads-up: this is an intermittent bug. #
# The below recipe is as close to a guarantee #
# of recreation as I can get you. #
# #
#
* Restart computer
* Log in to *one* tty only. I have not determined whether a second tty
login alters the behavior of this bug.
* Open a Bash prompt. I am using KDE, so my terminal emulator is Konsole.
* Do the command given in the title.
* In my case, this results in Konsole giving me an error:
Warning: Program '/bin/bash' crashed.
* Now, open another tab in your terminal emulator or open a new window of
it and do the command again.
No error this time. (Usually.)
* Log out of your GUI and log back in. Repeat. You'll see that again, you
get the error once per log-in.
-- Part 2 --
* Log out of GUI and log back in.
* Open terminal emulator. Log in to a shell within a shell with either
just "su" or "su [non-root user]"
* Enter the command. It crashes with:
Broken pipe
and kicks you back to the parent shell.
* Repeat the "shell within a shell" thing and, again, enter the command.
It does not break this time. Exit inner shell.
* Enter the command in the outer shell. Again, it does *not* crash
(usually).
-- Part 3 --
* Log out of your GUI.
* Does logging-out take longer than normal? Does it get really stuck and
force you to open another tty to restart your machine?
I have witnessed both. I have also witnessed it having little to no
effect on how long it takes to log out.
Additional Notes:
* One time I did Part 2 with just "su" and the outer shell still crashed. At
this moment, I consider the incident a fluke.
Again, understand that this bug is intermittent.
Re: Minor mistake in Bash manual
On 3/11/19 4:55 PM, Todd Lehman wrote:
> Hi!
>
> In the version dated 2019-Jan-07, I noticed the following mistake in the
> GNU Bash manual:
>
> | Associative arrays are created using
> | declare -A name.
>
> The period (".") after "name" should not be there.
Is this the man page or the texinfo manual? And where are you getting it,
since the versions in the bash-5.0 distribution are dated 7 December 2018?
--
``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: Minor mistake in Bash manual
On Tue, 12 Mar 2019, Chet Ramey wrote:
On 3/11/19 4:55 PM, Todd Lehman wrote:
Hi!
In the version dated 2019-Jan-07, I noticed the following mistake in the
GNU Bash manual:
| Associative arrays are created using
| declare -A name.
The period (".") after "name" should not be there.
Is this the man page or the texinfo manual? And where are you getting it,
since the versions in the bash-5.0 distribution are dated 7 December 2018?
Ah! Sorry, sorry, sorry. Forgot to include the URL in my original mail.
It appears here:
https://www.gnu.org/software/bash/manual/bash.html#Arrays
in the fourth verbatim text block. I'm assuming that's the latest &
greatest documentation, yes? It's dated 7 December 2018.
--Todd
