/bin/sh: line 2: `BASH_FUNC_ttr%%': not a valid identifier

[Brandon Allbery]

On Fri, Oct 10, 2014 at 6:13 AM, Barrie Stott <zen146410 at zen.co.uk> wrote:

> Wouldn't the stopping of function export from MacPorts' bash be a big
> restriction on bash use. For example, I want to be able to type "mvim",
> with or without parameters, to open a MacVim window. At present, I get the
> error:
> "/bin/sh: line 8: `BASH_FUNC_usenosql%%': not a valid identifier". Would
> not the prevention of function export prevent me from opening a MacVim
> window?
>

Nope. This is still the Shellshock attack vector, just with a little
protection around it: bash is opportunistically sucking in functions from
the environment and blindly eval-ing them, to no purpose in this case. If
anything, defining the wrong functions could break MacVim in very obscure
ways, instead of this obvious one. User functions should not be visible to
system level shell scripts; they should be deterministic, not randomly
modifiable by the user's environment.

The correct thing to do is, and always has been, to define functions in
your dotfiles and not have them affect arbitrary shells, only
interactive-mode ones. MacVim in particular knows how --- and when --- to
run the shell in this mode and get your functions. This is why the
Debian/FreeBSD patch is the correct one, but Bash upstream and Red Hat
refuse to do the right thing in this case... and this means, among other
things, that Shellshock-patched bash is not compatible with unpatched bash
if you define shell fucntions, which is the source of your immediate
problem.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20141010/107ed8d2/attachment.html>