Bug 151276
Summary: | IFS unset on startup | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Ralf Wildenhues <ralf.wildenhues> |
Component: | ash | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | pekkas |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | DEFER | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-03-15 22:32:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ralf Wildenhues
2005-03-16 16:55:06 UTC
Did you check whether FC4/FC5 is also affected? As FL doesn't do anything other than security bugfixes, this isn't going to be fixed in FC3, but it's important to make sure it has been appropriately fixed in the following releases. > Did you check whether FC4/FC5 is also affected?
No, I didn't. I can confirm RHEL 3 and RHEL 4 (which both have ash-0.3.8-20)
are also affected; RHEL 2 with ash-0.3.7-2 is not affected. I know newer ash
(I believe 0.5.3 is current) are not affected. Furthermore, RedHat 7.1
(ash-0.3.7-1) is not affected, but RedHat 9 (ash-0.3.8-8) is.
Sorry, I don't have access to other RedHat/Fedora versions.
OK, it seems all the following releases still use ash-0.3.8. As you've tested that RHEL4 is also affected, and I don't see anything that'd hint otherwise, I'll change the component to Red Hat Enterprise Linux. An alternative would be that you'd test this using latest 'ash' from Fedora rawhide and file this against FC5 when it comes out. In any case, the problem cannot be fixed for FC3, but obviously it'd be good to get it fixed for future releases. Sorry for the long delay in processing this bug report - I seem to have inherited ash maintenance without being made aware of it. ash is now deprecated in FC-5 and is no longer shipped. I do not believe this is a bug. Whereas in 0.3.7, the IFS variable was explicitly set in the environment to have its default value "\ \t\n" (in C syntax), now, that same default value is assumed if IFS is unset or nul. I have tested splitting with IFS unset, with fields separated by " " (space) or "\t" (tab) or "\n" newline, and it always works as expected. Now that ash works this way, it could cause RHEL users unecessary upset to change it back to work the old way . Scripts should assume that if IFS is unset, the default field separators "\ \t\n" are in effect. Having an unset IFS at startup is OK, if it behaves like <space><tab><newline>. But did they adjust the documentation then? It clearly stated that IFS was initialized at startup, and for stuff like save_IFS=$IFS this makes a difference. (Surely the corresponding issue has long been worked around upstream; but I think my first post indicated a discrepancy between documentation and actual behavior.) |