I'm trying to install BugZilla on our server. The issue is that perl scripts of BugZilla define the path as /usr/bin/perl, and my perl installation is located at /usr/local/bin/perl.

I've had this issue while installing other applications as well, i had to manually edit the interpreter paths.

How do you handle situations like these?

EDIT: I just noticed we've got two copies of perl on the server, one in the standard location, on in /usr/local/bin/perl, but which perl returns the former path.

Btw, here's the error I get when I run bugzilla's perl script

bash: ./checksetup.pl: /usr/bin/perl: bad interpreter: Permission denied
  • How come you don't have Perl in standard path? – ℝaphink Aug 28 '10 at 11:20
  • 2
    If the shebang line says #!/usr/bin/perl then it's not a Bash script. – Dennis Williamson Aug 28 '10 at 14:21
  • @Raphink: no clue, i inherited the server with my job. @Dennis: Hmm... i thought all shebanging scripts were called bash script. So in this case, it's just a perl script? – gAMBOOKa Aug 28 '10 at 18:03
  • 1
    bash is a shell, a programming language ; Perl is another programming language. Shebangs are here to tell which interpreter to use for a script (bash, Perl, Python, Ruby, etc.). Maybe you're confusing with batch scripts (instead of bash). – ℝaphink Aug 28 '10 at 21:16

You can create a soft link using ln that links /usr/bin/perl to /usr/local/bin/perl

ln -s /usr/local/bin/perl /usr/bin/perl
  • ln: /usr/bin/perl: File exists ... what now?! seems like there are two copies of perl, but which perl returns /usr/local/bin/perl – gAMBOOKa Aug 28 '10 at 18:04
  • 2
    Check the permissions on /usr/bin/perl are 755. If they are not then make them so with chmod 755 /usr/bin/perl. To find out whicn of your perl installations is being used check the shebang line at the top of the script. – Iain Aug 28 '10 at 18:39
  • 2
    @gAMBOOKa: the fact that which perl returns /usr/local/bin/perl is quite normal if you have a Perl installation there. /usr/local/bin usually overrides /usr/bin in the PATH. However, what matters to launch your scripts is the shebang in the script. Note that if the shebang had been #!/usr/bin/env perl, it would have pointed to /usr/local/bin/perl since it would have used your PATH. Now you can check the perms like @lain suggested, to check why /usr/bin/perl won't execute. – ℝaphink Aug 28 '10 at 21:19

We do this in my environment: we leave the system perl in /usr/bin/perl, and install our own interpreter in /usr/local/bin/perl; this allows us to retain a reliable perl that we know OS updates won't blow away.

I'd say the easiest way to get around this issue is to sidestep the shebang line altogether and just invoke those scripts using the perl interpreter you actually want to have execute them:

/usr/local/bin/perl /path/to/someBugzillaScript.pl

That gives you control over your execution environment without having to make system-level changes to accommodate the Bugzilla package.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.