[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue with Bash-4.3 Official Patch 27

From: Lorenz . Bucher . ext
Subject: Re: Issue with Bash-4.3 Official Patch 27
Date: Wed, 15 Oct 2014 19:49:12 +0200

Yes, you got it. I just gave an example to reproduce that Bug. In my case 
I didn't find the save script/binary yet. 
I use unset -f function as workaround. 

But anyway.
In my opinion I should trust a shell not violating their own rules and be 
able to import their own variables.
So the % character should be allowed to be used in variable names.

Von:    Greg Wooledge <wooledg@eeg.ccf.org>
An:     Eduardo A. Bustamante López <dualbus@gmail.com>, 
Kopie:  Lorenz.Bucher.ext@rohde-schwarz.com, bug-bash@gnu.org
Datum:  10/15/2014 05:58 PM
Betreff:        Re: Issue with Bash-4.3 Official Patch 27

On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López 
> On Wed, Oct 15, 2014 at 03:38:01PM +0200, 
Lorenz.Bucher.ext@rohde-schwarz.com wrote:
> > variables with suffix "%%" can't be set/exported.
> > This makes problems restoring environments which where saved by 
> > programs like printenv (see example below)
> I'm not sure if this is a bug, because I doubt that function
> exporting was intended to use that way. Just source a file with the
> function definitions...

My take was that he's got some script that does an environment
save/restore and the function exports broke it.  He may not especially
care about restoring the functions, as long as they don't get in the
way of the real variables.

That said, his save/restore technique is going to break on *any*
environment variable that isn't a valid shell variable name, which
includes a much larger set of things than just BASH_FUNC_foo%%.  He
simply hasn't encountered any of these other things yet (and may
never encounter them in real life, depending on his environment).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]