Bug 151276

Summary: IFS unset on startup
Product: Red Hat Enterprise Linux 4 Reporter: Ralf Wildenhues <ralf.wildenhues>
Component: ashAssignee: Jason Vas Dias <jvdias>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: 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
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):
ash-0.3.8-20

How reproducible:
Always

Steps to Reproduce:
1. $ ash -c 'set | grep IFS'
2. $ ash
$ echo ".$IFS."
3.
  

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 05:58:58 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.


Comment 2 Ralf Wildenhues 2006-03-14 07:04:18 UTC
> 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 07:27:05 UTC
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 22:32:47 UTC
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 07:01:32 UTC
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.)