Re: Tightening up specification of /bin/sh

[Arthur Korn <arthur@korn.ch>]

Hi

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.

to

"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
/bin/sh alternative.

ciao, 2ri
-- 
We'll try to make different mistakes this time.
	-- Larry Wall in "Apocalypse Two"