The short answer is: this isn't possible with env — at least not in any portable way...
The problem is that the kernel (which is handling shebang execution) typically only has very rudimentary argument parsing facilities, i.e. it parses the shebang line into an interpreter and one optional argument. In your specific case, this means that /usr/bin/env would be passed "perl -wT" as a single argument, if you were to try something like
#!/usr/bin/env perl -wT
as you might have extrapolated from studying the env manpage.
(Though, as far as I remember, there's one notable exception - Solaris - which does actually handle this correctly, by passing multiple arguments to the interpreter.)
Thing is that env is not doing any further argument splitting on its own, so it would try to execute a program named "perl -wT", which would of course fail under normal circumstances... There isn't much you can do about it.
However, if the idea is to avoid hardcoding the absolute path to Perl, you could use the shell (instead of /usr/bin/env), in combination with Perl's option -x, e.g.
#!/bin/sh exec perl -Sx -T $0 "$@" #!perl -w # Perl code starts here print "interpreter: $^X\n"; print "script: $0\n"; print "arguments:\n"; printf " '%s'\n", $_ for @ARGV;
-x makes Perl skip any non-perl garbage up to #!perl. -S would make the script be found along the search path (if so desired).
Option -T would have to go on the exec perl ... command line (as shown), while other options (like -w) could also go on the #!perl line.
Also see perlrun for other similar hacks/wrappers...
In reply to Re: calling perl via env....
by almut
in thread calling perl via env....
by perlknight
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |