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. [1] http://www.openwall.com/lists/oss-security/2014/09/25/13 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
