When scripting, what's the difference between #!/usr/bin/perl and #!/usr/bin/env perl?

Obviously this applies e开发者_开发知识库qually with python, bash, sh, etc substituted for perl!

Quentin's answer below was clearly correct, and so I've accepted it, but I guess what I actually meant was 'what are the pros and cons of the two ways of using #! to invoke perl/python/bash as the interpreter of a script?'

---

One references a common place that perl is installed. The other references a common place that env is installed and asks it what the path to the default perl is.

---

These are good rules, if you have a good reason to break them, don't hesitate to do so:

Use #!/usr/bin/env perl where possible for portability between heterogenous systems. But that's a dumb way to do it because it makes the assumption that the Perl that is first in the path is also the Perl you always want. That may not be so, and usually when there are several Perls on a system they are there for a certain reason.

A better approach is to package scripts up in a CPAN-ready distro. Distribute the distros to the systems where you want to have them installed and install them in the usual way (manually or with the CPAN toolchain), specifiying the full path to perl or cpan. During that process, the shebang line is rewritten to the correct path to Perl.

Examples:

tar -xvf Local-OurCompany-Scripts-1.000.tar.gz
cd Local-OurCompany-Scripts-1.000

## automated installation
/usr/bin/cpan .
# or perhaps
/opt/ourcompany/perls/perl-5.14.2/bin/cpan .

## manual installation
/usr/bin/perl Makefile.PL ; make ; make install
# or perhaps
`which perl5.14.2` Makefile.PL ; make ; make install

---

Using env to find the executable, rather than finding it yourself, does an additional exec, but that shouldn't really matter most of the time. It's convenient and I often use it myself.

However, I have had issues with people using env in system scripts. On one occasion, installing a /usr/local/bin/perl broke my system so that I could not update it anymore until I resolved the problem. On another occasion, installing a /usr/local/bin/python broke the ID3 tagger I was using. I think this is more a packaging issue than an inherent problem with env. If you're installing something on a system, why are you carefully checking that it has a version of Python that satisfies all of your dependencies if you're just going to leave a shebang line that fishes around for any old version of Python each time it is run?

---

I can give you a concrete example:

Imagine you have a LAMP package installed in /opt/ (i.e. XAMPP) that includes it's own perl executable, libraries and pakage manager.

You actually want to run that executable so you add the path to the LAMP executables in your PATH environment variable (PATH="/opt/XAMPP/bin:$PATH").

Now any script that uses "#!/usr/bin/env perl" will execute the perl binary in the LAMP stack directory. The other path will execute the pre-installed perl binary in your system, in "/usr/bin/perl".

It's up to you to decide what's better for your perl script.