[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tightening up specification of /bin/sh

On Mon, May 21, 2001 at 09:25:33AM -0500, Steve Greenland wrote:
> On 21-May-01, 05:22 (CDT), Patrik Hagglund <patha@softlab.ericsson.se> 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


Reply to: