On 2014-09-26 08:51 -0600, Eric Blake wrote: > On 09/26/2014 08:45 AM, Nick Bowler wrote: > > On 2014-09-25 15:08 -0700, Linda Walsh wrote: > >> Eric Blake wrote: > >>> Where I'm coming from is that in portable shell programming, you _can't_ > >>> assign a value to f()=... The fact that portable programs are now > >>> slammed with the notion that some values cannot be portably assigned > >>> to a variable... > >> --- > >> slammed? It's not like this is new... > > [...] > >> As other have said: > >> > >> «Geir Hauge wrote: Bash has had this feature since "forever"» > >> > >> «Pierre Gaston wrote: How many instance have you found since the > >> introduction of this feature more than 20 years ago?» > > > > Since I don't use bash it's not surprising that I've never noticed any > > problem. > > > > But I try to write scripts that are portable to bash, because I know > > that many people do use it. What I learned from this is that bog- > > standard assignments like this: > > > > foo=$1; export foo > > > > are not portable to bash, and may fail to work correctly depending on > > the user's input. > > They are not portable to broken bash. But the argument in these threads > is that bash's implementation of function exports should be changed so > that _fixed_ bash will once again be POSIX compliant and let this > bog-standard assignment work regardless of contents. If Chet accepts > Florian's patch [1] to change function exports to use BASH_FUNC_foo()= > instead of foo= (which is what Red Hat is already using in their fixes > pushed today), then this POSIX compliance bug in broken bash will be > avoided. I agree. This sounds like a simple and effective solution. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
