According to the Linux Filesystem standard, it must be:
:Because shell script interpreters (invoked with #!<path> on the first
:line of a shell script) cannot rely on a path, it is advantageous to
:standardize the location of them. The Bourne shell and C-shell
:interpreters are already fixed in /bin, but Perl, Python, and Tcl are
:often found in many different places. /usr/bin/perl, /usr/bin/python,
:and /usr/bin/tcl should reference the perl, python, and tcl shell
:interpreters, respectively. They may be symlinks to the physical
:location of the shell interpreters.
(Section 4.3 of the FSSTND)
>
> >make the test 'if [ -x `which perl` ]'.
> Assuming the shell supports which.
It's a shell script; the shell is sh (or a clone; bash, ash, etc). Sh
doesn't support which. Which is a command in /usr/bin on most
systems, but not all, so we can't rely on it.
> What's wrong with just trying to run perl? $PATH is surprisingly
> (or not if you have some common sense) helpful for this sort of
> thing.
This relies on $PATH being set to include /usr/bin; highly probable,
but not certain. Perl being in /usr/bin is certain on a
FSSTND-compliant system. If perl isn't in /usr/bin it is unlikely to
be in root's path unless it's in /bin or /sbin, in which place the
sysadmin should be shot anyway. Checking /usr/bin is a better choice,
since it will find it on all Linux (FSSTND-compliant) systems.
TTFN,
Sumner