[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Dan,
	Please see comments below.

	Thanks,
	Don

>From dank@alumni.caltech.edu Tue May  9 14:00:17 2000
>From: Dan Kegel <dank@alumni.caltech.edu>
>Subject: (austin-group 790) Re: #! -- reconsideration?
>To: Don Cragun <Don.Cragun@eng.sun.com>
>Cc: schilling@fokus.gmd.de, loewis@informatik.hu-berlin.de,
>        mcinquini@speedera.com, austin-group@opengroup.org, mats@laplaza.org,
>        lsb-discuss@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.  
>
>Agreed.
>
>>         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
directory.)

>- Dan
>
>p.s.
>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 
>http://www.opengroup.org/onlinepubs/007908799/xcu/getconf.html 
>
>-- 
>Entia non sunt multiplicanda praeter necessitatem.



Reply to: