The main difference ist that /usr/bin/perl is a fixed path to one perl (which is usually the one that ships with your operating system), while /usr/bin/env perl will take the first perl in $PATH. | [reply]
[d/l]
[select] |
I know it is OT, but ... does /usr/bin/env perl makes much sense at all? In this case, I could simply write perl. I feel that env is mainly useful when used together with options, such as env -i for providing an empty environment for a command...
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l]
[select] |
You are right that /usr/bin/env perl and perl will behave the same way on the command line. However, as JavaFan points out below, they are quite different when used on the shebang line (since the former will look for perl in your path, while the latter won't).
| [reply]
[d/l]
[select] |
| [reply] |
| [reply]
[d/l]
[select] |
And rightly so, assuming you're on Unix.
On Unix, the first two bytes of an executable are "magical" - they tell the kernel what kind of executable it is. It may be a binary (depending on the OS, it may be able to run different styles of binaries), or it may be something that's to be fed to an interpreter. The magical bytes to signal that are 0x23 0x21, which in ASCII looks like "#!". Then the kernel takes the rest of the line (up to the next horizontal whitespace, or newline) as the name of the interpreter to run, and then feed the program as its input.
So, if your program starts with
#! perl
and execute the program, the kernel will try to execute "perl" (assuming your OS skips leading whitespace; your program is more portable if it doesn't have whitespace after the #!). But the kernel isn't going to peek in your environment settings, and won't try all the directories in your $PATH. So it won't find "perl".
| [reply]
[d/l] |