Hello! I have the following problem in Centos 7: I go under the root and execute the command:

ls `perl -e "print qq(@INC\n);"` 

I get:

 perl5 

Next, do:

 sudo su 

and after

 ls `perl -e "print qq(@INC\n);"` 

And I get the paths of the pearl and the connected modules.

If I without sudo su try to run any script like this:

 perl blabla.pl 

nothing happens and nothing swears.

The question is why? What is wrong with the root? Why doesn't perl work under it?

I fulfill:

 $ echo $PATH; type perl; which perl; file $(which perl) 

From under the root:

 [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin perl is hashed (/usr/local/bin/perl) /usr/local/bin/perl /usr/local/bin/perl: empty 

from under sudo su:

 [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/sbin:/bin:/usr/sbin:/usr/bin perl is hashed (/bin/perl) /bin/perl /bin/perl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=68e24ea1ba03faac3442ad4d448635bc8feceb4b, stripped 
  • please attach to the question, output $ echo $PATH; type perl; which perl; file $(which perl) $ echo $PATH; type perl; which perl; file $(which perl) $ echo $PATH; type perl; which perl; file $(which perl) in both cases. - aleksandr barakin
  • @alexanderbarakin, from under sudo su: [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/sbin:/bin:/usr/sbin:/usr/bin perl is hashed (/bin/perl) /bin/perl /bin/perl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=68e24ea1ba03faac3442ad4d448635bc8feceb4b, stripped [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/sbin:/bin:/usr/sbin:/usr/bin perl is hashed (/bin/perl) /bin/perl /bin/perl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=68e24ea1ba03faac3442ad4d448635bc8feceb4b, stripped [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/sbin:/bin:/usr/sbin:/usr/bin perl is hashed (/bin/perl) /bin/perl /bin/perl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=68e24ea1ba03faac3442ad4d448635bc8feceb4b, stripped - Relajado
  • from under the root: [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin perl is hashed (/usr/local/bin/perl) /usr/local/bin/perl /usr/local/bin/perl: empty [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin perl is hashed (/usr/local/bin/perl) /usr/local/bin/perl /usr/local/bin/perl: empty [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin perl is hashed (/usr/local/bin/perl) /usr/local/bin/perl /usr/local/bin/perl: empty - Relajado
  • To add a question, please edit the question text below. - aleksandr barakin
  • @alexanderbarakin, done - Relajado 8:36

2 answers 2

 [root@game ~]# echo $PATH; type perl; which perl; file $(which perl) /root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin perl is hashed (/usr/local/bin/perl) /usr/local/bin/perl /usr/local/bin/perl: empty 

Obviously, the empty file /usr/local/bin/perl must be deleted (or at least renamed).

and you should also add the /sbin and /bin directories to the contents of the $PATH environment variable. it is probably better to do this by removing the redefinition of this variable that occurs in one of the files: /etc/profile , /etc/bash.bashrc , /root/.bashrc , /root/.bash_profile , /root/.bash_login , /root/.profile .

  • / usr / local / bin / perl is FreeBSD-way, in linux, EMNIP, this is / usr / bin / perl - Majestio
  • I can quote from there "This is the standard code for the Filesystem Hierarchy Standard (FHS), a standard for UNIX-like systems. It’s ... The keyword "most". In fact, the law has not been written for a long time. FreeBSD 9.0 / usr / bin / perl, FreeBSD 11.0 / usr / local / bin / perl, Linux Funtoo / usr / bin / perl, Mac OS X 10.9.1 / usr / bin / perl ... this is from what's on hand . - Majestio

Obviously something is wrong with the paths ($ PATH)

  • try to find, use under root: find / -type f -iname "perl"
  • on found (preferably obvious) use: / full_path / perl -v
  • a working pearl with a full path was found, it remains to edit the environment, namely $ PATH, where the comments were listed in the comments

And more ... "/ root / perl5 / bin" - should concern !!! SYSROOT is a pearl that is not from our galaxy. Clean, align the paths of each account.

  • trying to find - why look for what is already "found"? see the very last line in the question text. - aleksandr barakin 9:39
  • if the paths have "/ root / perl5 / bin" should be alarming ... but not several copies / versions of the pearl in the system. "Your" whereis or which browse just the directories accessible by paths. The find command searches for everything, nothing is lost from it. Something like that. Therefore, your "found" still need to double-check. - Majestio
  • double - check - why check what has already been verified? quote from the question: "and I get the path of the pearl and the connected modules." // I think you did not quite understand what was stated in the question. however, it is not surprising - the question is very messy. - aleksandr barakin
  • pancake! so I suggested first find a go! There is a possibility of having multiple copies of pearl / symlink / dead symlink. Only running with an absolute path and the option of taking a version will show that the executable file is live and executable. Although ... I sprinkle my head with ashes, yes, in find you need to add the option -type f to exclude simlinks. - Majestio