(austin-group 790) Re: #! -- reconsideration?

Don Cragun Don.Cragun at Eng.Sun.COM
Wed May 10 09:49:36 PDT 2000

	Please see comments below.


>From dank at alumni.caltech.edu Tue May  9 14:00:17 2000
>From: Dan Kegel <dank at alumni.caltech.edu>
>Subject: (austin-group 790) Re: #! -- reconsideration?
>To: Don Cragun <Don.Cragun at eng.sun.com>
>Cc: schilling at fokus.gmd.de, loewis at informatik.hu-berlin.de,
>        mcinquini at speedera.com, austin-group at opengroup.org, mats at laplaza.org,
>        lsb-discuss at lists.linuxbase.org
>X-Accept-Language: en
>Don Cragun wrote:
>>         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 ... 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.  
>>         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.
>So you're proposing that a package that wants to be portable will
>rewrite all of its shell scripts at install time and replace the thing
>following #! with the absolute path to the POSIX-compliant shell
>located in the first directory listed in `getconf PATH`?

Actually, the install scripts should use an absolute path of sh in the
first directory in the list of directories supplied by the command
	`getconf -v desired_environment PATH`
that contains an executable file named sh after verifying that the
desired environment is supported.

>That's reasonable, I suppose, but it's not something I've seen done
>in practice yet.  Has anyone else observed this in the wild?

Since getconf's -v option was new in Single UNIX Specification version
2, it isn't surprising that this hasn't been used much so far.  As more
complex standards are approved with similar, but slightly different,
requirements I expect to see this used much more.
>Now that you've explained your objection to /bin/posixsh, can you
>comment on /usr/posix/bin/sh?

Both /bin/posixsh and /usr/posix/bin/sh are hardcoded pathnames that do
not give any indication of which version of the POSIX standard is being
referenced.  For this discussion they have exactly the same problems.
(Other people have already indicated a problem requiring a /usr

>- Dan
>You didn't really mean that -v was a useful flag for our
>purposes here, right?  -v is used to select machine word sizes
>and the like, not to select Posix vs. xpg3 etc., according to 
>Entia non sunt multiplicanda praeter necessitatem.

More information about the lsb-discuss mailing list