Red Hat Bugzilla – Bug 151276
IFS unset on startup
Last modified: 2007-11-30 17:07:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1
Description of problem:
$IFS is not set on startup of this ash version. This is a bug as it clearly contradicts the manpage (see at the end, environment variables).
Shell scripts can break because of this. I found this while testing an unreleased Libtool version.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ ash -c 'set | grep IFS'
2. $ ash
$ echo ".$IFS."
Actual Results: 1. no output, showing IFS was unset
2. prompt; the two dots showing IFS was empty or unset.
Expected Results: IFS needs to be exactly space, then tab, then newline.
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.)