#! Processing Problem

[Bill Lorensen]

Sorry if this is a known problem, but here goes.

Any program can be invoked to process an interpreter script by putting
the program name on the first line of a script preceeded by a #!. This
is most often used to invoke a shell such as /bin/csh or /bin/sh.
However, I think I have discovered (probably rediscovered) a bug in
first line processing. There appears to be a hard limit on the length
of the path name. This is 29 characters on a Sun3. I have also found
the same problem on:

	Sun4, Convex C220, Encore Multimax, Stellar GS1000

This seems to happen regardless of the shell you are running. I
suspect the first line processing is handled directly by execve.

Related man sections follow:

>From from csh(1)
    "When a pathname is found that  has  proper  execute  permis-
     sions,  the  shell  forks a new process and passes it, along
     with its arguments to the kernel (using the execve(2) system
     call).   The kernel then attempts to overlay the new process
     with the desired program.  If  the  file  is  an  executable
     binary (in a.out(5), the kernel succeeds, and begins execut-
     ing the new process.  If the file is a text  file,  and  the
     first  line begins with #!, the next word is taken to be the
     pathname of a shell (or command) to interpret  that  script.
     Subsequent  words on the first line are taken as options for
     that shell.  The kernel  invokes  (overlays)  the  indicated
     shell, using the name of the script as an argument."

>From execve(2)
    "An interpreter file begins with a  line  of  the  form  ``#!
     interpreter  [arg]''.  When an interpreter file is execve'd,
     the system  execve's  the  specified  interpreter.   If  the
     optional  arg is specified, it becomes the first argument to
     the interpreter, and the name  of  the  originally  execve'd
     file becomes the second argument; otherwise, the name of the
     originally execve'd file becomes the  first  argument.   The
     original  argument are shifted over to become the subsequent
     arguments.  The zeroth argument, normally the  name  of  the
     execve'd file, is left unchanged."

The following csh script illustrates the problem:

#! /bin/csh
#
#	illustrate file name length bug during #! processing
#
unset noclobber
set dir = "/tmp/1"
set n = 1
/bin/rm $dir/garf
mkdir $dir
ln -s /bin/cat $dir/garf
while ($n < 256)
	mv  $dir ${dir}1
	set dir = ${dir}1
	echo "#! $dir/garf" >testit
	echo "This is a test, this is only a test" >>testit
	chmod +x testit
	if ( ! { testit } ) then
		echo "********* Fails at length `expr $dir/garf : '.*'`"
		break
	endif
	@ n = $n + 1
end
/bin/rm $dir/garf
rmdir $dir
Bill Lorensen
	US Mail:GE Corporate Research and Development
		P.O. Box 8
		Bldg KW Room C207A