[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: Bash forgets sourcefile and linenumber of read-in functions

From: Greg Wooledge
Subject: Re: Bug: Bash forgets sourcefile and linenumber of read-in functions
Date: Tue, 12 Mar 2019 08:34:58 -0400
User-agent: NeoMutt/20170113 (1.7.2)

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.


address@hidden:~$ cat /etc/debian_version 
address@hidden:~$ bash -c 'f() { :; }; export -f f; env | grep BASH_FUNC'
BASH_FUNC_f()=() {  :

address@hidden:~# cat /etc/debian_version 
address@hidden:~# 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]