On 9/26/14, 4:17 PM, Eric Blake wrote: > At any rate, this seems like an inadvertent regression that could be > patched; are you willing to propose such a patch? The gist of the > matter is that the code base must use the same decision on what forms a > valid function name as it does in deciding what exported non-variable > names in the environment can be reinstated as functions. I'm fairly > certain that Chet will be reasonable about this, and after the worst > fires are put out, we can revisit this.
It wasn't inadvertent, but it is not intended to be permanent. Here is the long explanation, cut from a discussion earlier today on a different mailing list: The original set of patches (bash43-025 and its siblings) tightened the restrictions on allowable imported function names, forcing them to be shell identifiers. The shell itself, when not in posix mode, allows virtually any character that is not a shell metacharacter to appear in a function name (that's basically the difference between an identifier and a word in shell-grammar-speak). This results in the ability to define functions like this: $ function /bin/echo () { builtin echo whoops; } and have this happen: $ /bin/echo whoops along with exporting these functions and importing them without complaint. This is obviously bad, and I removed the ability to do this in the first patch in the event that someone figured out an easy way to remotely specify an arbitrary variable name before we implemnted something to stop it. The problem is that it's too restrictive. There are folks who have taken advantage of this flexibility to define, use, and export functions like STD::what::does::this::do which are no longer allowed. This is a pretty bad break with backwards compatibility. So what's your opinion on the appropriate set of restrictions? This is a question that goes farther than what a particular shell will import, since I'm going to align the restrictions on what functions a shell will import from the environment with what functions that shell will let a user define. That means that a posix-mode shell will require imported functions to be valid identifiers, but a non-posix mode shell will allow words. The original check that was in bash-4.3 does this. What additional checks should there be? I can see starting with rejecting function names that can be confused with pathnames. (And I'm not interested in rehashing decisions that were made 25 years ago, and I am completely aware that this "violates" Posix. That's why it doesn't do this in posix mode.) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/