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/)
