Re: Issue with Bash-4.3 Official Patch 27
No, I can't. $ foo%%="bar" foo%%=bar: command not found Or better said not in the normal way $ set foo%%=bar -- Mit freundlichen Grüßen Lorenz Bucher TechConnect GmbH Im Auftrag der/on behalf of Rohde & Schwarz GmbH & Co. KG Postfach 80 14 69 • 81614 München Mühldorfstraße 15 • 81671 München Telefon:(089) 4129-15684 Mail: lorenz.bucher@rohde-schwarz.com Internet: www.rohde-schwarz.com Von:Chet Ramey An: lorenz.bucher@rohde-schwarz.com, wool...@eeg.ccf.org, Kopie: bug-bash@gnu.org, "Eduardo A. Bustamante López" , chet.ra...@case.edu Datum: 10/16/2014 03:09 PM Betreff:Re: Issue with Bash-4.3 Official Patch 27 Gesendet von: bug-bash-bounces+lorenz.bucher.ext=rohde-schwarz@gnu.org On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote: > But anyway. > In my opinion I should trust a shell not violating their own rules and be > able to import their own variables. That's not the issue. The shell can import variables like that just fine, as evidenced by exported functions actually working. The question is whether or not `export' lets you set and export non-identifiers. It does and should not. > So the % character should be allowed to be used in variable names. No, shell variable names should continue to be shell identifiers. You can already use `%' (any character, really) in environment variable names. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: Issue with Bash-4.3 Official Patch 27
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 An: Eduardo A. Bustamante López , Kopie: lorenz.bucher@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 wrote: > On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com wrote: > > variables with suffix "%%" can't be set/exported. > > This makes problems restoring environments which where saved by external > > 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).
Issue with Bash-4.3 Official Patch 27
Hello,
in refer to
http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
with suffix "%%" can't be set/exported.
This makes problems restoring environments which where saved by external
programs like printenv (see example below)
I saw this issue on Ubuntu 12.04 with
bash version GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
examples:
$ foo() { echo "bar"; }
$ export -f foo
$ echo "export BASH_FUNC_foo%%='$(printenv BASH_FUNC_foo%%)'" | tee ./env
export BASH_FUNC_foo%%='() { echo "bar"
}'
$ source ./env
bash: export: `BASH_FUNC_foo%%=() { echo "bar"
}': not a valid identifier
$ export BASH_FUNC_foo%%='() { echo "bar"; }'
bash: export: `BASH_FUNC_foo%%=() { echo "bar"; }': not a valid
identifier
$ export BASH_FUNC_foo='() { echo "bar"; }'
bucher_l@zim:/vobs/1GP1AdminVob/Tools/ldapadmin$ echo $BASH_FUNC_foo
() { echo "bar"; }
