When writing scripts, what is the difference between #! / Usr / bin / perl and #! / Usr / bin / env perl?

Question

Obviously, this applies equally to python, bash, sh, etc., replaced by perl!

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

Answer 1

One refers to the common location in which perl is installed. Others refer to the usual place where env is installed, and asks what the default path to perl is.

Answer 2

These are good rules, if you have a good reason to break them, feel free to:

Use #!/usr/bin/env perl , where possible, for portability between heterogeneous systems. But this is a dumb way to do this because it makes the assumption that Perl, which is the first in the way, is also the Perl that you always want. This may not be the case, and usually when there are several Perls in the system, they exist for a reason.

The best approach is to package the scripts in a distribution ready for CPAN. Distribute distributions on the systems where you want to install them and install them in the usual way (manually or using the CPAN toolchain), indicating the full path to perl or cpan . During this process, the shebang string is rewritten to the correct Perl path.

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 

Answer 3

Using env to find the executable, rather than finding it on its own, performs additional exec, but this does not really matter in most cases. This is convenient, and I often use it myself.

However, I had problems with people using env in system scripts. At one point, installing /usr/local/bin/perl violated my system so that I could not upgrade it until it resolves the problem. Otherwise, installing /usr/local/bin/python broke the ID3 tag I used. I think this is more of a packaging problem than an inherent problem with env . If you are installing something on the system, why do you carefully check that it has a version of Python that satisfies all your dependencies, if you are just going to leave the shebang line that is going to every old version of Python every time it starts?

Answer 4

I can give a concrete example:

Imagine you have the LAMP package installed in / opt / (i.e., XAMPP), which includes its own perl executable, libraries, and the pakage manager.

In fact, you want to run this executable to add the path to the LAMP executables in the 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. Another way is to execute the pre-installed perl binary on your system, in "/ usr / bin / perl".

It's up to you what is best for your perl script.