Re: Tightening up specification of /bin/sh
On Mon, May 28, 2001 at 10:21:55PM +0200, Patrik Hagglund wrote:
> Zack Weinberg wrote:
> > 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?
>
> The quote _is_ from the POSIX standard (I have the ISO version
> ISO/IEC 9945).
Okay, so you can confirm that XPG/4 quotes POSIX here. Great.
> > It's my contention that nearly no one has access to the genuine
> > standard or even a reliable source describing the genuine
> > standard.
> >
> > 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.
>
> Hmm.. You now seems to prefer a number of implementations as the
> _primary_ reference, rather than a secondary reference point as
> stated previously.
In fact, yes, I do think that in the case of the shell, implementation
practice should override standards, particularly in the case where
following the letter of the standard will break backward compatibility.
One may take this too far, as Solaris does - their /bin/sh is still
an archaic implementation with quirks out the wazoo. Where POSIX.2 is
unambiguous I am content with it. Where it is ambiguous, I want the
ambiguity resolved in favor of compatibility with existing practice.
> > 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
>
> The problem is that in this case they don't do it the same way.
If the added requirement only has force when all existing
implementations do something the same, then it's useless. It is
intended to apply to the condition where all existing implementations
but one do something the same, and unambiguously label that one
maverick as buggy. I could try to make this more explicit.
> According to POSIX they shouldn't ignore the value in the
> environment. At least ash seems to get this right:
My reading of the XPG/4 page is that shells are allowed to honor or
ignore it as they see fit. Therefore, this is a case where my
proposal triggers. Ash honors the value in the environment, but bash,
pdksh, AT&T ksh, and /bin/sh from three different proprietary Unix
clones all ignore it. Therefore, under my proposal, ash is buggy.
If POSIX says explicitly that it must be honored, that's news to me.
> My conclusion remains, trying to refer to a consensus - current
> implementation practice - that doesn't exist isn't useful.
I'm not convinced that consensus doesn't exist.
--
zw I *will* wrestle it into shape eventually. I *will* clean it out,
*without* resorting to the redirection of a major navigable river.
-- Ray Radlein on lumber rooms
Reply to: