----- "Eduardo A. Bustamante López" <dual...@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?