portability of non-shell scripts

[Mathias Koerber]

In article <1136 at galaxia.Newport.RI.US> dave at galaxia.Newport.RI.US (David H. Brierley) writes:
>This is one of those problems that has no real solution short of forcing
>everyone to upgrade to a version of the kernel that supports the #!
>mechanism (yes, the #! mechanism is implemented *inside the kernel*!!).
>Since you can make a pretty good guess as to what the odds of this happening
>are you can apply those same odds to coming up with a solution.

I haven't been following this discussion and just happened to read it here,
so I might ask something already discussed:
My system doesn't support #!, so I can't test it.
Does #! use the PATH, when finding only the name of the executable, or do I 
have to provide the full path/filename for the shell. I mean, my perl is
likely to sit somewhere else than Larry's (in fact it does). So I'd provide
a PATH on my login shell, which points to my local/bin, export it and
exec() then can search the shell to find it. I only would have to provide

	#!perl
	#

as the first line of the script. And anyone could create a file (maybe also in
local/bin, that looks like

	# where does perl reside on this machine ?
	PERL=/usr/local/bin
	# where does csh reside ?
	CSH=/bin
	# where does xxx reside ?
	XXX=/usr/local/xxx/bin
	#
	PATH=$PATH:$PERL:$CSH:$XXX
	export PATH
	# maybe export PERL CSH XXX

another solution (something to agree upon across systems):

	agree upon an exported SHELL-VAR for every shell like:

	# where does perl reside?
	PERL=/usr/local/bin/perl
	export PERL

run this at login time to set the VARS,

and use

	#!$PERL

in the scripts (would that work ?)

Just asking,

Mathias


-- 
Mathias Koerber  | S iemens             | EUnet: koerber.sin at nixdorf.de
2 Kallang Sector | N ixdorf             | USA:   koerber.sin at nixdorf.com 
S'pore 1344      | I nformation Systems | Tel: +65/7402852 | Fax: +65/7402834
* Packed with Power, SNIckers really satisfy  (or do they? Ask them gals :-) )*