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 -Wp,-
D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -
m64 -mtune=generic
uname output: Linux mintaka.chemi.muni.cz 3.7.3-101.fc17.x86_64 #1 SMP Fri Jan
18 17:40:57 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.2
Patch Level: 39
Release Status: release
Description:
BASH allows creating shell functions with identifier containing characters
outside the "POSIX safe" set, for example the dash character ("-"). These
functions can be marked for exporting via the environment by declare -x.
When a child shell is started as /bin/sh, usually the problematic functions
are ignored (not imported from the environment, not displayed by "set"), but
still the environment is passed on to child processes.
However, given the right circumstances the /bin/sh child shell tries to
import the function from the environment and blows up with "not a valid
identifier".
This happens in the implicit subshell created in shell_execve() when execve()
fails on a command that is in fact a shell script lacking the shebang line.
Repeat-By:
This can easily be reproduced using these three scripts:
---BEGIN FILE "test"---
#!/bin/bash
function foo-bar() { echo "Foo!"; }
declare -fx foo-bar
./test2
---END FILE "test"---
---BEGIN FILE "test2"---
#!/bin/sh
echo "in test2"
./test3
---END FILE "test2"---
---BEGIN FILE "test3"---
echo "in test3"
---END FILE "test3"---
Set all three chmod +x and execute ./test (preferably in an empty environment
using "env -i ./test" to get rid of possibly interfering functions from your
own shell).
---EXPECTED OUTPUT---
in test2
in test3
---END---
---ACTUAL OUTPUT---
in test2
/bin/sh: line 1: `foo-bar': not a valid identifier
---END---
Fix:
A simple fix would be to make initialize_shell_variables() silently ignore
functions that can't be imported because of illegal characters. However, this
would only fix BASH subshells. To get this done properly, one would have to
encode
the function identifiers into the POSIX-safe character set when exporting to
environment and decode back the original identifier in
initialize_shell_variables().
Best regards,
Tomas Trnka
