Hey Eduardo - Jay is one of many - the fix for the parser exploit is using the wrong code to decide if the identifier is valid for a function. And it doesn't have to.
Jay should certainly not "fix" his working scripts - which, btw, could have been working for the last 20 years. i guess i'll submit a working patch if necessary. Chet, is that necessary? On Sep 26, 2014, at 1:08 PM, Jay Freeman (saurik) <sau...@saurik.com> wrote: > ----- "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? Thanks, Brian -- Brian J. Fox Technology Partner The Okori Group, LLC A: 901 Olive St., 93101 O: 805.617.4048 C: 805.317.4048
