On Mon, May 21, 2001 at 09:25:33AM -0500, Steve Greenland wrote: > On 21-May-01, 05:22 (CDT), Patrik Hagglund <[EMAIL PROTECTED]> wrote: > > I don't see what you mean by "the initial value of the IFS > > variable". Is there anything that is unspecified for field > > splitting in IEEE Std. 1003.2-1992? Isn't "If IFS is not set, the > > shell shall behave as if the value of IFS were the <space>, <tab>, > > and <newline> characters." (page 123) enough? > > You apparently missed the recent flamewar on this topic. Some people > apparently interpet "the shall behave as if the value of IFS were" as > "the shell shall set the value of IFS to". So yes, the standard is clear > to those people who are used to reading standards. Others tend to read > more into them than is there.
This misses the point. The phrase being quoted here is _not_ from 1003.2-1992, it's from the XPG/4 webpage describing the shell. It may also be in 1003.2-1992 but can anyone prove that? I can't. Who here has ever actually read a copy of the genuine standard? It's my contention that nearly no one has access to the genuine standard or even a reliable source describing the genuine standard. (K+R 2nd ed. is a reliable source describing the 1989 C standard. The XPG/4 webpage is not a reliable source describing 1003.2.) That being so, the only way to determine what is or is not portable shell is to test a putatively portable feature on many different shells. "Many" is a shaky term, but I for one feel comfortable arguing that if five different shells all do something the same way - e.g. they all set IFS to <space><tab><newline> on startup, ignoring any value in the environment - then any other shell which is found to do something else is buggy, and it doesn't matter what the standard says. zw
