Re: Tightening up specification of /bin/sh
> > 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.
This can be verified from the documents that are readily available.
Take, for instance, the Open Group's web page documenting the shell,
<http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html>. This
is not a reliable guide because it documents the Single Unix standard,
not the POSIX standard, and it does not describe the differences.
(They also never actually come out and say whether this is the
official text of SUS, but I think it's reasonable to assume it is.)
However, we know that Single Unix is a superset of POSIX. Therefore,
if the Single Unix standard leaves something unsaid, explicitly
unspecified, or ambiguously worded, it is reasonable to assume that
POSIX does too.
I encourage you to go read that web page and decide for yourself how
well specified the shell language is.
> > 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.
You reject the possibility that there is a genuine ambiguity which one
author has read differently from the other two, and each insists that
their reading is correct? This has come up in real life twice that I
am aware of.
> 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.
I would bet that they don't, and I am indeed extremely suspicious of
such claims. I would support a move to require SUS compatibility
instead of POSIX, since that specification is readily available.
# From http://standards.ieee.org/catalog/posix.html:
#
# 1003.2d-1994 IEEE Standard for Information Technology--Portable
# Operating System Interface (POSIX&)--Part 2: Shell and
# Utilities-Amendment 1: Batch Environment
# Print: 152 pages [1-55937-512-4] [SH94269-NYF] $81.00
# * IEEE Mbr: $65.00
# PDF: [0-7381-0633-X] [SS94269-NYF] $122.00
# * IEEE Mbr: $98.00
These things are not cheap.
> 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.
This leaves nowhere to go if the author of the script and the author
of the shell have an unresolvable disagreement. Again, this has come
up in real life twice at least.
...
> > 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.
The POSIX C standard is much better specified than the shell standard
(I have actually read the POSIX C standard), hence you can say what is
and is not a bug in the implementation. This is not true of the shell
standard.
...
> 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).
You again neglect the case where two maintainers disagree and will not
be reconciled. That is something one would prefer not to assume will
happen, but when it has happened in the past, one cannot then ignore
the possibility that it will happen again.
zw
Reply to: