> It's not backwards compatible, but who cares? The only time it
> matters is if you are mixing old and new bash ON THE SAME SYSTEM,
> and TRYING TO EXPORT FUNCTIONS BETWEEN THEM.
It might happen during the update of bash. A bash process exec()ed
before the update would fail to export a function
> I'd much rather prefer the use of an invalid shell name (such as
> f()=...) than a valid shell name (BASH_FUNCTION_foo=()...).
Using a BASH_ prefix has some advantages:
* Anyone setting such a variable, might expect it could change the
behaviour of bash. Any script allowing setting untruste
Hello,
As the interface is not specified, would it make sense to:
* add a prefix (use BASH_FUNCTION_foo instead of foo for exported
function foo);
* still expand the variable if it matches the 'exported function'
pattern.
The first point would reduce the probability of a clash with
a us
Hello,
As the interface is not specified, would it make sense to:
* add a prefix (use BASH_FUNCTION_foo instead of foo for exported
function foo);
* still expand the variable if it matches the 'exported function'
pattern.
The first point would reduce the probability of a clash with
a us
