Re: REGRESSION: shellshock patch rejects valid function names

[Jay Freeman (saurik)]

----- "Eduardo A. Bustamante López" <dualbus@gmail.com> wrote:

> Well, what did you expect? You're relying on undocumented features.
...
> So, fix your scripts, perhaps?

I am sorry I seem to have offended you so much to have warranted this form of 
response :(.

> It's common knowledge that if you rely on undocumented stuff, your
> code will eventually break, like it did now. It's not a regression
> though, nowhere in the manual you'll find that colons are allowed in
> function names.

Please note that I am by far not the only person who uses colons in function 
names: Google's style guide for shell actually states that using :: in function 
names to separate library names from function names and package names within 
library names is their best practice.

http://google-styleguide.googlecode.com/svn/trunk/shell.xml?showone=Function_Names#Function_Names

"Lower-case, with underscores to separate words. Separate libraries with ::. 
Parentheses are required after the function name. The keyword function is 
optional, but must be used consistently throughout a project." "If you're 
writing a package, separate package names with ::."

If we are going to be adamant that this functionality--functionality that many 
people have relied on since the dawn of bash (the earliest version of bash I 
have access to has always allowed this), functionality that the code went out 
of its way to support (that check_word flag exists SOLELY for this purpose: 
this isn't accidental), functionality that "makes sense" (as it allows function 
names to replace any normal executable command), functionality that one of the 
world's largest software companies not only uses but actively encourages 
third-parties to use--is a "duh, you shouldn't have done that, fix your s**t" 
scenario, can we at least 1) document this behavior change and 2) start a 
deprecation schedule on function/export supporting these identifiers in the 
first place?