Red Hat Bugzilla – Bug 55205
bash 2.04.21/2.05.8 env var incompatibility
Last modified: 2008-05-01 11:38:01 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; m18) Gecko/20010110 Netscape6/6.5 Description of problem: Create the following shell script: func() { echo $var } var=xxx func func var=yyy func When run on bash 2.04.21, this produces xxx yyy When run on bash 2.05.8, it produces xxx xxx yyy My understanding is that setting the value of a variable on the command line is supposed to temporarily affect the environment for that command only. This would mean the 2.04 behavior is correct, and the 2.05 behavior is wrong. I see no mention of the change in the bash FAQ or COMPAT file. As a practical matter, this incompatibility between the two versions caused an existing shell script to fail, so there's an existence proof that the change in behavior matters to at least one user. :-) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: See Description field above. Additional info:
I'm not sure whether or not this change is intentional (might be, because a function is not actually a separate process). I've sent a message to the base maintainer, waiting for reply.
From: Chet Ramey <chet@nike.ins.cwru.edu> Feature. POSIX.2, section 3.9.5, says: When a function is executed, it shall have the syntax-error and variable-assignment properties described for special built-in utilities in the enumerated list at the beginning of 3.14. Section 3.14 says, in part: Variable assignments specified with special built-in utilities shall remain in effect after the built-in completes... Note that bash behaves this way only when in posix mode. Chet
Note that this was a real incompatibility that cost me an afternoon to track down (after upgrading from RH7.1 to 7.2). The shell script in my case was invoked by /sbin/ifup-local. Since the shell behaves differently in POSIX mode, the circumstantial evidence points to some change in the way ifup-local is invoked between 7.1 and 7.2 -- perhaps it's now posixly-correct when it wasn't before. It might be nice to understand what changed, so that no other breakage occurs as a result of the same incompatibility...