Bug 151276 - IFS unset on startup
IFS unset on startup
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ash (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-03-16 11:55 EST by Ralf Wildenhues
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 17:32:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ralf Wildenhues 2005-03-16 11:55:06 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):

How reproducible:

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.

Additional info:
Comment 1 Pekka Savola 2006-03-14 00:58:58 EST
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.
Comment 2 Ralf Wildenhues 2006-03-14 02:04:18 EST
> 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.
Comment 3 Pekka Savola 2006-03-14 02:27:05 EST
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.
Comment 4 Jason Vas Dias 2006-03-15 17:32:47 EST
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.
Comment 5 Ralf Wildenhues 2006-03-16 02:01:32 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.