#! -- reconsideration?

Don Cragun Don.Cragun at Eng.Sun.COM
Tue May 9 13:23:03 PDT 2000

Dan and Joerg,
	I also like the simplicity of /bin/posixsh, but until we can
guarantee that no future amendment or revision of a POSIX standard will
ever place any incompatible requirements on "standard" utilities, this
just won't work.  Implementations have to have a way to provide
applications with a way to access a stable "environment" that won't
change even when a new version of the standard is published.  The
Solaris 8 Operating Environment currently supports applications written
to lots of different specifications and standards (including, but not
limited to: 4.3BSD, SVID3, XPG3, XPG4, SCD 2.4.1, SUS, SUSv2, and
various versions of POSIX some with K&R C support, some with C Standard
support as defined by the 1998 C Standard, and some with support for
both compilers).  This is all done by choosing appropriate compiler
flags and settings for the PATH environment variable consistent with
the environment the application wants to use.  Other implementors will
have a different set of specifications they will decide they need to
support based on requests from their customers.
	The POSIX standards and the Single UNIX Specifications have
wisely chosen not to specify hard coded pathnames for the standard
utilities.  Implementations need to give users a description of how to
find the set of utilities specified by the standards they support, and
the standards need to specify how to find the rest of the standard
utilities once you get to that point (such as Austin Group revision
draft 3 XCU's
		getconf -v specification PATH
command.)  Then applications that want to use #! have to be configured
to find the absolute pathname for the utility they want invoked as the
interpreter by #! as part of their installation processing.
	Just using env as the interpreter isn't sufficient to find the
POSIX standard shell (The Solaris 8 release provides /usr/bin/env and
/usr/xpg4/bin/env and the shell that you get when you specify "env sh"
is different for these two.  And, specifying /usr/bin/env with sh as an
argument won't get you a POSIX conforming shell.  [Doing so would break
thousands of scripts that our customers have written.])


>From austin-group-request at opengroup.org Tue May  9 12:29:15 2000
>Resent-Date: 9 May 2000 19:24:25 -0000
>From: Dan Kegel <dank at alumni.caltech.edu>
>Subject: Re: #! -- reconsideration?
>To: Joerg Schilling <schilling at fokus.gmd.de>
>Cc: loewis at informatik.hu-berlin.de, mcinquini at speedera.com,
>        austin-group at opengroup.org, donnte at microsoft.com, mats at laplaza.org,
>        ajosey at rdg.opengroup.org
>X-Accept-Language: en
>Resent-Message-ID: <"pSODVEVBm_O.A.ngC.iXGG5"@postman.opengroup.org>
>Resent-To: austin-group at opengroup.org
>Resent-From: austin-group at opengroup.org
>X-Mailing-List: austin-group:archive/latest/786
>X-Loop: austin-group at opengroup.org
>Resent-Sender: austin-group-request at opengroup.org
>Joerg Schilling wrote:
>> I would prefer /bin/posixsh It is easy to memorize and as the POSIX shell
>> is something special, I cannot find any objections against this name
>> for this purpose.
>I do like /bin/posixsh, but Andrew Josey <ajosey at rdg.opengroup.org> objected in
>> I'd favour /usr/posix/bin/sh
>> since there may be other utilities where there is a clash
>> with existing behaviour that we deem serious enough to
>> support two different versions.
>Also, Solaris uses /usr/xpg4/bin/sh, and it might be reasonable to
>use the same metascheme (/usr/STANDARDNAME/bin/sh) here.
>- Dan
>Entia non sunt multiplicanda praeter necessitatem.

More information about the lsb-discuss mailing list