On Fri, Sep 26, 2014 at 10:36 AM, Eric Blake <eblake@xxxxxxxxxx> wrote:
> On 09/26/2014 08:22 AM, Zack Weinberg wrote:
>>
>> The question in my mind is, is exporting functions a POSIX shell feature?
>> If not, perhaps it should just be scrapped altogether.
>
> Why not read POSIX and find out for yourself?
I would normally, but I am traveling right now and limited to things
that work on my phone. The Open Group's site is not one of those
things, unfortunately. Thanks for checking for me.
> export -f is not required by POSIX, so it is a shell extension. But
> people DO rely on it, so nuking it now would be a backwards incompatible
> break. I'd still like to keep it, but with a smarter implementation.
Fair enough...
> Other messages on the list have suggested smarter implementations, such
> as using 'BASH_FUNC_foo()=...' instead of 'foo=() {' as the magic for
> doing the export, thus eliminating the collision.
That should help. I might be a bit more aggressive, e.g.
_BASH_FUNC_<8 random hex chars>_<name>() = body of function
The 8 random hex chars come from something unpredictable but stable in
the filesystem, so even if an attacker can somehow put () in an
environment variable name they can't reasonably generate these names.
(I think 2^-64 is probably improbable enough for this.)
And I'd take the curly braces off the function body, too, to ensure
the original bug can't possibly come back.
> it would be okay if we let /bin/bash continue to import functions
> by default, but have bash invoked as /bin/sh refuse to do imports by
> default. If the ability to import functions becomes conditional on
> argv[0], then I also suggest that bash have a 'set -o' option or 'shopt'
> setting that can let the user override the default (a way to invoke
> /bin/sh but with function imports, or a way to invoke /bin/bash but with
> no functions).
Sure.
zw
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
