2

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
4
  • How come you don't have Perl in standard path?
    – raphink
    Aug 28, 2010 at 11:20
  • 2
    If the shebang line says #!/usr/bin/perl then it's not a Bash script. Aug 28, 2010 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, 2010 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).
    – raphink
    Aug 28, 2010 at 21:16

2 Answers 2

8

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
3
  • 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, 2010 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.
    – user9517
    Aug 28, 2010 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.
    – raphink
    Aug 28, 2010 at 21:19
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .