Re: REGRESSION: shellshock patch rejects valid function names

[Brian J. Fox]

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) <saurik@saurik.com> wrote:

> ----- "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?


Thanks,

Brian
--
Brian J. Fox
Technology Partner
The Okori Group, LLC
A: 901 Olive St., 93101
O: 805.617.4048
C: 805.317.4048