| Summary: | >=app-shells/bash-4.3: 'local FOO' does not 'unexport' variables | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://lists.gnu.org/archive/html/bug-bash/2014-05/msg00003.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Bisected it down to: commit ac50fbac377e32b98d2de396f016ea81e8ee9961 Author: Chet Ramey <chet.ramey@case.edu> Date: Wed Feb 26 15:36:43 2014 Bash-4.3 distribution sources and documentation Not that the way bash upstream fails at git makes this very helpful. Arfrever reported this about a year ago: https://lists.gnu.org/archive/html/bug-bash/2014-05/msg00003.html and the final result was WAI: https://lists.gnu.org/archive/html/bug-bash/2014-05/msg00021.html Oh right, I could've expected nothing less from this idiot upstream. We have a feature for N years, then upstream suddenly declares it is a bug and 'fixes' it, breaking compatibility and stuff. I should be grateful. The useful bug is finally fixed, and we should set empty variables instead which change behavior in software! please refrain from ad-hominem attacks. they're entirely pointless and no one likes to read them. |
A quick sample: export FOO=11 foo() { local FOO env | grep FOO } foo in bash-4.2 and older, FOO is not exported in the function scope. With bash-4.3_p42-r1, the original value is preserved. This seems to happen independently of what I do to the local FOO variable -- exporting, unsetting explicitly... BASH_COMPAT seems not to affect it. I'm going to bisect this a bit more.