Re: #! -- reconsideration?
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.])
Thanks,
Don
>From austin-group-request@opengroup.org Tue May 9 12:29:15 2000
>Resent-Date: 9 May 2000 19:24:25 -0000
>From: Dan Kegel <dank@alumni.caltech.edu>
>Subject: Re: #! -- reconsideration?
>To: Joerg Schilling <schilling@fokus.gmd.de>
>Cc: loewis@informatik.hu-berlin.de, mcinquini@speedera.com,
> austin-group@opengroup.org, donnte@microsoft.com, mats@laplaza.org,
> ajosey@rdg.opengroup.org
>X-Accept-Language: en
>Resent-Message-ID: <"pSODVEVBm_O.A.ngC.iXGG5"@postman.opengroup.org>
>Resent-To: austin-group@opengroup.org
>Resent-From: austin-group@opengroup.org
>X-Mailing-List: austin-group:archive/latest/786
>X-Loop: austin-group@opengroup.org
>Resent-Sender: austin-group-request@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@rdg.opengroup.org> objected in
>http://www.debian.org/Lists-Archives/lsb-spec-9812/msg00022.html
>
>> 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.
Reply to: