Re: Tightening up specification of /bin/sh
Zack Weinberg schrieb:
> 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?
Ok, I see.
Can we change the last sentence in:
> ! 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.
"Consensus behavior is determined by testing all shells which
register for the /bin/sh alternative in the distribution the script
is meant for."
Note that there is currently no /bin/sh alternative. (why not?)
I think it would be really bad to have scripts in the distribution
which work with some /bin/sh but don't with others. If a given
script doesn't work with a /bin/sh alternative, hardwire it's shell
or, if the shell makes to much trouble, don't register it for the
We'll try to make different mistakes this time.
-- Larry Wall in "Apocalypse Two"