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
gAMBOOKa
  • 999
  • 6
  • 19
  • 34
  • How come you don't have Perl in standard path? – raphink 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). – raphink Aug 28 '10 at 21:16

2 Answers2

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
user9517
  • 115,471
  • 20
  • 215
  • 297
  • 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. – user9517 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. – raphink Aug 28 '10 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.

Jeff Albert
  • 1,987
  • 9
  • 14