[lsb-discuss] Shebang definition

[Andrew Josey]

Tobias
If you search
http://www.opengroup.org/sophocles/show_archive.tpl?source=L&listname=austin-group-l&first=1&zone=G&searchstring=%23%21&pagesize=80
There are 143 messages on #!. There was a proposal to include it
in version 3 of the Single UNIX Specification but it did not carry

The proposal was as follows:

from
http://www.opengroup.org/austin/docs/austin_51r2.txt

 _____________________________________________________________________________
 OBJECTION                                        Enhancement Request Number 6
 ajosey:opengroup.org                                 Bug in XCUd3 (rdvk#  25)
 {bwg2000-004p2}                         Sun, 30 Apr 2000 08:53:37 +0100 (BST)
 _____________________________________________________________________________
 Accept_____    Accept as marked below_X___     Duplicate_____     Reject_____
 Rationale for rejected or partial changes:


 Add after sentence 2 of Bullet 1 of section 2.1 on XCU D3 page 35,
line 1203 :

<XSI shade>On XSI conformant systems, if the first two characters of a
file are "#!", it shall behave as described for Executable Scripts in
Section nn.nn.nn.nn.<XSI shadeoff>


 Fixup Rationale on page 35 of XCU, by changing line 1227

"a conforming application"  to "a POSIX conforming application".

and then adding:

"An XSI conforming application can use the construct #!, since on
XSI conformant systems this is defined to denote an
an Executable Script, which matches historical practice.
Invention of new meanings or extensions to the #! construct
were rejected since they are beyond the scope of this document."


 Add new part into the Shell Command Language description
 (will need to find a suitable location)

 [XSI shade on]

 Executable Script

 XSI-Conformant systems shall support executable scripts. A successful
 call to a function of the exec family with an executable script as
 the first parameter shall result in a new process, where the process
 image that is started is that of the interpreter. The path name of
 the interpreter follows the "#!" characters .

 If the executable script has a first line

         #! interpreter [arg]

 then the interpreter shall be called with an argument array
 consisting of an unspecified zeroth argument, followed
 by arg (if present), followed by a path name for the
 script, followed by the arguments following the zeroth argument
 in the exec call of the script.

 No shell operations (as described above in section 2.1) shall
 be performed on the first line of an executable script.

The behavior shall be unspecified if the first line of the executable
script does not meet all of the following criteria:

1.  the first line shall be in one of the formats below:
        "#!%s\n" interpreter
        "#!<delta>%s\n" interpreter
        "#!%s<delta>%s\n" interpreter arg
        "#!<delta>%s<delta>%s\n" interpreter arg

2.  the interpreter argument shall be an absolute pathname of an
    executable file other than an executable script,

3.  the interpreter argument and the arg argument, if present, shall
    not contain any quoting characters,

4.  the interpreter argument and the arg argument, if present, shall
    not contain any whitespace characters, and

5.  the length of the first line shall be no longer than 80 bytes.





 Rationale (XRAT):


 The working group did not reach consensus to adopt this as a core
 requirement, that is for POSIX conformancing applications, however
 existing practice on UNIX systems indicated that it should be added
 as an XSI extension, and this was brought into the scope of this
 revision by The Open Group Base Working group resolution BWG2000-004. 
 The scope of this feature is to document existing practice and not
 to invent.

 Applications must not assume that the standard utilities will
 be available in any  particular named directory. For example it cannot be
 assumed that standard versions of awk and sh will be available
 as "/bin/sh" or "/bin/awk" respectively, since implementations are
 permitted to provide non standard versions of the utilities in these
 directories.

 It is recommended that an installation script for
 executable scripts, use the standard PATH returned by a call to the
 getconf utility with the argument PATH, combined with the command
 utility to determine the location of a standard utility:

 For example to determine the location of the standard sh utility:
         command -v sh

 On some systems this might return
         /usr/xpg4/bin/sh

 Note that the installation script should ensure that the returned
 pathname is an absolute pathname prior to use, since a shell builtin
 might be returned for some utilities.

 in XCUd3 page 900 sh APPLICATION USAGE

 Change the example from

 #! /bin/sh -

 to

 #! /usr/bin/sh -


Add the following text:

Applications should note that the standard PATH to the shell cannot be
assumed to be either "/bin/sh" or "/usr/bin/sh" and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the  returned pathname is an absolute pathname and not a shell builtin .

For example to determine the location of the standard sh utility:
         command -v sh

On some systems this might return
         /usr/xpg4/bin/sh

Furthermore, on systems that support executable scripts (the #! construct),  
it is recommend that applications using executable scripts
install them using  getconf -v  to determine 
the shell pathname and update the #! script appropriately as it is 
being installed (e.g. with sed), for example:

#
# Installation time script to install correct posix shell pathname
#
#
# Get list of paths to check
#
Sifs=$IFS
IFS=: 
set $(getconf PATH)
IFS=$Sifs

#
# Check each path for 'sh'
#
for i in $@
do
        if [ -f ${i}/sh ];
        then
                Pshell=${i}/sh
        fi
done

#
# This is the list of scripts to update.   They should be 
# of the form '${name}.source' and will be transformed to '${name}'
# each script should begin
#
#!INSTALLSHELLPATH -p 
#
scripts="a b c"

#
# Transform each script
#
for i in ${scripts}
do
        sed -e "s|INSTALLSHELLPATH|${Pshell}|" < ${i}.source > ${i}
done




Then in 

http://www.opengroup.org/austin/docs/austin_57.txt

XCU ERN 36:
ISSUE: In the light of this comment, the ORs would like to reconsider the
inclusion of #! (TOG in particular). Return to explicitly unspecified what
happens with #!.  
OR FORMAL VOTE - WG15 keep, TOG remove, IEEE remove.

Donn Terry  observed that #! is a very useful tool, and although the
current implementations are not suitable for standardization, that he
would very much like to see a version that was suitable proposed for
standardization in the future.  He encouraged implementation development
in that area.

XCU ERN 36 follows


 _____________________________________________________________________________
 Comment                                         Enhancement Request Number 36
 donnte:microsoft.com                         Bug in XCUd4 Batch 2 (rdvk#  29)
 [DST-60]                                      Fri, 22 Sep 2000 15:35:24 -0700
 _____________________________________________________________________________
 Accept_____    Accept as marked below_X___     Duplicate_____     Reject_____
 Rationale for rejected or partial changes:

Delete the section

 _____________________________________________________________________________
 Page: 2265  Line: 2176  Section: 2.10


 Problem:
 80 bytes; in a 2-byte multibyte character set, or in Unicode, this
 is 40 characters.  For a 4-byte code (full 10646) this is 20 characters.
 I understand that this is an implementation limit, but in an
 internationalized
 context this becomes a fairly significant limit.

 Also, in what locale is this interpreted?  In particular, if there are
 multiple locales where the representation of the portable filename
 character set varies, in which locale is this interpreted.  (Remember,
 this is happening in the kernel, not user space, so the concept of
 locale gets a lot spookier to deal with.)  (Is it required to be
 "in the character set of the filesystem", even if not operating
 in a compataible locale.)  (All other locale issues can be hidden
 by wrappers, but this can't be because it's, like executable files
 in general, handled directly by the OS.)

 (Consider, for example, an OS that names files in (8-bit) 646 like
 characters, but with a locale set for Unicode (so the, for example,
 awk program is written in Unicode).  How does the user create a
 file where the first few bytes are in 646 (not even the first line,
 because the arguments are in Unicode).  Also consider that many
 (most?) Unicode files themselves begin with a feff or ffef flag word.)

 Action:
 To address the first problem, require implementations to accept
 at least 80 characters in the "default" character set.
 However, I don't see a good solution to the second problem, so...

 Delete the section.

regards
Andrew