Re: Tightening up specification of /bin/sh
On Mon, May 21, 2001 at 04:43:11AM +0200, Marcus Brinkmann wrote:
> On Sat, May 19, 2001 at 09:13:31PM -0700, Zack Weinberg wrote:
> > I'd like to tighten this up a bit by requiring that /bin/sh adhere to
> > the consensus of implementations, where POSIX leaves things
> > unspecified.
>
> I disagree, on the grounds that this exchanges an arguably specific standard
> for a completely vague description of /bin/sh behaviour with no
> understandable gain for Debian.
Rather than repeat myself at length I would like to refer you to my
responses to Arthur Korn, who said much the same thing. Perhaps you
will find the alternate proposal there more to your liking.
I will reiterate, however, that the issue from my point of view is
that the standard is not specific at all, and even where it is, it is
not readily available, so how does anyone know what it specifies? In
practice, the vague description I laid out is more reliable than any
impression of what the standard might be, acquired nth-hand from man
pages and so forth (I include the Open Group's webpage outlining the
shell language in this category).
> Debian does have complete control over the shell scripts it ships, so if
> shell scripts have POSIX incompatibilities, we can fix them. The fear of
> bugs one might encounter when changing /bin/sh for a completely untested
> POSIX compatible shell should not stop us from making this requirement.
>
> Debian does not have the requirement that scripts are portable to a large
> set of systems with unknown shells, which have bugs or weird behavior in
> border cases. We can always fix our supposedly POSIX compatible shells if
> they turn out to be not so compatible.
I should mention that I am pretty exclusively an upstream maintainer
myself and I do tend to come at these things from that point of view.
That said, would you not prefer to fix one shell in a border case,
than to fix a potentially very large number of shell scripts, which
the upstream maintainers may deny are broken? In good faith, since
(once more) they have no access to the standard and can only guess at
what it might require by the testing procedure I outlined.
> Indeed, we don't have the resources or possibility to test our scripts
> against a whole number of shells, or in any other way determine what your
> idea of /bin/sh is supposed to be. I am not even sure we have five
> supposedly POSIX compatible shells to test against (not to mention we can have
> any number of shells which "claim" to be POSIX compatible, because such a
> claim can be a fraud).
I deliberately chose a number larger than the number of POSIX shells
in Debian (three: pdksh, ash, bash). This was to ensure that testing
was not limited to shells in Debian.
That was probably unreasonable.
> You mention that disputes trigger endless discussions, like echo -n. Your
> proposal opens the door to even more discussion. In fact, it requires
> endless discussions, because your proposal is completely unspecific about
> the details. The attempts you make to specify what is not specified (by
> making it a necessity to number five shells claiming compatibility, by
> favouring POSIX over other features, by putting the decision in the hand of
> the maintainer where no agreement is reached) are failing short because they
> can easily circumvented formally and thus will not be effective in
> preventing such discussions.
Certainly the wording could be improved, but I think that a general
constraint which can be applied to any number of cases is preferable
to a large number of specific constraints.
zw
Reply to: