Re: Tightening up specification of /bin/sh
On Mon, May 28, 2001 at 11:03:14AM -0700, Zack Weinberg wrote:
> 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.
No, I don't, sorry.
> 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?
First thing, in all your proposals is the sentence that says that POSIX is
very unspecific. As, like you say, the standard is not easily to come by, we
should not make such bold statements without a way to verify it.
> 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).
If you have a shell script and two shells, and all three claim POSIX
compatibility, and the script doesn't run equally well in both shells, then
there is obviously a violation of the standard somewhere. We can expect
that at least the authors/maintainers of the two shells claiming POSIX
compatibility to have a copy of the standard, or we will have to be
suspicious about their claim. So a situation where we have absolutely no
idea if and what POSIX specifies about something should be quite rare, and
I'd be satisfied to leave this battle to shell implementers. If we come
into a double mill, backing off by using less disputed shell features is
always an option as well.
[...]
> > 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.
No, I do not prefer this. I prefer to fix whatever is broken, regardless of
the amount of brokeness. I am actually doing this by fixing programs to
compile on the GNU/Hurd, which we say is POSIX compliant, but isdifferent from
Linux and BSD in that it doesn't specify PATH_MAX (not to mention
legacy symbols like MAXHOSTNAMELEN etc). So we have to fix all those
programs that are not strictly POSIX compatible, but rely on optional
(limiting!) POSIX features which are not available on the Hurd.
> > 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.
Yes. I see your point, but for a Debian standard document, this is not so
good ;) I think it's a fundamental problem with you proposal, that it isn't
a good fit for Debian, where we have different ways to attack this issue.
(As we have complete control over what we ship).
[...]
> 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.
Then we have probably reached a point where we simply disagree in our
preferences.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: