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...
|