Solutions to common problems running Perl scripts on Unix systems.
Unix systems read the first line of files to run, and look for something to execute the subsequent data with. If this line is broken due to invisible characters, an invalid path, or text format problems, the script will not run. Note that the error below mentions the filename being run, not the typo of the bin directory name.
$ ls -l broken
-rwxrwxr-x 1 jmates jmates 40 15 Oct 11:12 broken
$ cat broken
#!/usr/bni/perl -l
print "Hello World";
$ ./broken
zsh: no such file or directory: ./broken
To check the interpreter path, copy and paste the path to see if the file can be found.
$ head -1 broken
#!/usr/bni/perl -l
$ file /usr/bni/perl
/usr/bni/perl: Can't stat `/usr/bni/perl' (No such file or directory)
Also check for invisible characters in the text file. Invisible characters could be added by accident, or if the file uses a format Unix cannot read: legacy Macintosh \r or Internet linefeeds \r\n may cause problems on Unix, which expects \n.
The head and od commands reveal invisible characters. The following example, for macos.pl, contains Macintosh \r line breaks.
$ head -1 macos.pl | od -c
0000000 # ! / u s r / b i n / p e r l
0000020 - w l \r p r i n t " H e l l o
0000040 W o r l d " ; \r
0000051
$ cat -v macos.pl
#!/usr/bin/perl -wl^Mprint "Hello World";^M
Tools like dos2unix or BBEdit can convert line breaks between different formats used by Unix, Windows, and legacy Mac OS applications. Unix requires \n linebreaks.
$ perl -i -ple 's/\r/\n/g' macos.pl
$ perl -i -ple 's/\r//g' dos.pl
A trick on Unix systems to run perl code relies on the Unix convention to run the shell if no other interpreter can be found:
perl <<'EOF'
print "Hello World\n";
And no, #!/usr/bin/env perl will never be a “better” way to find perl, just yet another sometimes useful, sometimes flawed method. For example, software depot may divide software deploys into different components, each with their own install of Perl. In this case, env would pick the random first one in PATH, not perl from the correct component, unless PATH is somehow always properly adjusted for code that runs under the component. Easier to use a software depot version of env (not /usr/bin/env) that is aware of the depot components, in such cases. The Practice of System and Network Administration covers software depot in more detail.