Re: Tightening up specification of /bin/sh
On Sun, May 20, 2001 at 11:36:04AM +0200, Arthur Korn wrote:
> Zack Weinberg schrieb:
> > <p>
> > ! The standard shell interpreter `<tt>/bin/sh</tt>' is a
> > ! symbolic link to a POSIX compatible shell. Since the POSIX
> > ! standard for shells leaves important areas unspecified,
> > ! wherever it is lacking, `<tt>/bin/sh</tt>' shall follow the
> > ! <em>consensus behavior</em> of other shell interpreters.
> > ! Consensus behavior is determined by testing at least five
> > ! shell interpreters which claim to be POSIX compatible.
>
> I oppose, this way lies madness.
>
> Ether a shellscript is POSIX compliant, and works on all POSIX
> compliant shells, or it's not, then you are free to do
> #!/bin/bash or whatever, but don't rely on a nonstandard feature
> being present in other shells as well. Just testing some shells
> is _no_ substitute for standard compliance.
If the POSIX shell standard were like, say, the C standard, then I
would agree with you, but it isn't. The C standard makes clear what
is and is not standard-specified behavior. Books which describe
standard C are readily available, and the standard itself can be had
from ANSI for US$18.
The POSIX shell standard is ambiguously written in a large number of
areas; it can be difficult to tell what is and is not specified. I am
aware of no books that describe standard shell. The standard itself
costs upward of US$100. The XPG/4 official shell manpage _is_
available online for free, but cannot be trusted to match the POSIX
standard, and policy specifies POSIX.
Also, most vendors these days can be trusted to implement standard C
more or less correctly. This is not true of their /bin/sh
implementations. Upstream development has to worry about N different
commercial Unix shells with slightly different bugs, not just Debian's
three Bourne shells which are bug-free by comparison.
Common upstream practice when trying to write portable shell,
therefore, is to write a test script and run it on as many different
shells as one can get one's hands on. And if it does the same thing
on all of them, one assumes that the code is portable. I have no
complaint if you wish to call this mad, but it is the only approach
that works.
The set of features that one finds to be portable shell, by the
try-it-and-see approach, limited to shells which actually claim POSIX
conformance (if you don't make that limitation the portable feature
set gets a lot smaller), is in practice a small superset of the
features which are specified by POSIX. What I want is for policy to
recognize the existence of this superset, and permit shell scripts to
rely on it. They already do, after all. Take away those features and
you're faced with an unknown amount of breakage - and in my opinion,
fixing all that breakage would be time wasted. Better simply to
ensure that /bin/sh does what we all expect it to, whether that is
codified by POSIX or not.
This has come up before. Remember the endless argument over echo -n?
In the end that led to an explicit additional requirement on /bin/sh
being written into policy. The only alternative I see to my proposal
is to continue to add explicit additional requirements on /bin/sh,
with associated endless arguments, every time someone changes their
shell implementation incompatibly. Do we really want that?
--
zw ...It's not easy for cognitive scientists to get grants if they
are working on questions of any theoretical interest. (To ensure
this is a main function of the institution of peer review.)
-- Jerry Fodor, _The Mind Doesn't Work That Way_
Reply to: