| Summary: | bash-3.2_p20+ aborts "source" commands when encountering read only variables | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jory A. Pratt <anarchy> |
| Component: | Current packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andriy155, base-system, david, ferringb, gentoo_eshoes, jakub, jieryn, kamensky.fb, polynomial-c, rose, s |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lists.gnu.org/archive/html/bug-bash/2007-08/msg00075.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 200044 | ||
| Attachments: |
test script
use egrep to filter out readonly variables |
||
|
Description
Jory A. Pratt
2007-08-25 03:50:23 UTC
It seems like there's come kind of problem with nested "source" statements. I've masked bash-3.2_p25 to prevent others from hitting this. Looks like this is caused by bash32-020, as bash-3.2_p19 works fine while bash-3.2_p20 shows this error. Created attachment 129123 [details]
test script
Anyway this bug can seriously damage system... if one will be upgrading packages. I made out to damage udev, hald & nvidia-drivers. Pretty hard to get to know what is going on as for instance udev was clearing /proc/sys/kernel/hotplug :) *** Bug 190166 has been marked as a duplicate of this bug. *** *** Bug 190375 has been marked as a duplicate of this bug. *** *** Bug 191565 has been marked as a duplicate of this bug. *** *** Bug 191981 has been marked as a duplicate of this bug. *** considering the bash change is standards compliant, i think we need to put together a new "source" function that basically weeds out readonly variables from the file based on the active environment before sourcing it Created attachment 136358 [details, diff]
use egrep to filter out readonly variables
This patch seems to work. The readonly variables are filtered out by egrep when the environment is saved. This solution is pretty simple. It would probably be a little more complex to implement a safe "source" function.
doing it at the save step should probably be fine for most uses implementing source wouldnt be terribly hard, but if you already have stuff in place to do it at saving ... In bash-3.2_p25.ebuild I've added a blocker for <sys-apps/portage-2.1.4_rc1 so that we can unmask bash-3.2_p25 and emerge will automatically adjust the merge order such that portage is upgraded before bash. I've left bash-3.2_p25 in package.mask for the time being, until portage-2.1.4_rc1 has had more testing. (In reply to comment #11) > doing it at the save step should probably be fine for most uses > > implementing source wouldnt be terribly hard, but if you already have stuff in > place to do it at saving ... Doing it at *just* the save step means that further extensions of readonly vars in the portage env can cause new breakages, and means you're slightly screwed with the collection of vdb envs that are already out there. You're going to need the filtering at the reload level imo, not just saving (think this bug proves out why save filtering alone isn't enough). |