We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Easy question !?

cl071997 asked
Medium Priority
Last Modified: 2010-04-20

Im running Openlinux and when I try to execute a shellscript or a perl script, I cant´do it. I need to write
"perl <perlscript>". I have changed it to mode 755 och I am the owner (root) of the script. I start the script with "#!/usr/bin/perl -w". I´ve done this a thousand times with the wonderful Slakware version.

Claes Lindvall
Watch Question

what's the error message?


The error message is "command not found"...
The perl directory is included in the path ( /usr/bin/perl).

check with od -c if these are realy the first chars in your script:

You also may remove the  -w  option in the first line (don't know if you shell or OpenLinux has a problem with that).


I tried with od -c and there were nothing but the characters I wrote in the file. I even tried without -w.
I have another linuxbox with RedHat 4.2 , the sparc version. It´s the same with that one, not even a shell script will work without "sh" in front of it.

which shell are you using? try another one (bash, tcsh, etc.)


Sorry, I´m already using bash, and I even tried with "sh"...
Any other ideas...?


The error message "command not found"  sounds that /usr/bin/perl does not exist or that /usr/bin/perl has wrong mode.
Or your shell did not know about the "#!" escape, unbelievable.
Have you tried another script, like  #!/bin/sh  ?

Can you give us the output of "ls -l /usr/bin/perl"?

Unlock this solution and get a sample of our free trial.
(No credit card required)


Here it comes
-rwxr-xr-x   2 root     root       504764 Apr 22  1997 perl



I read your suggestions pablocosta, but everythings looks fine. Perl in /usr/bin is not a link but a binary file, and no - I didn´t upgrade my slakware. Yes, there is only one "perl" file in the system and only one perl installation.

This is strange, I suppose you can execute a script, both perl and shell in RedHat and OpenLinux. It´s just an ordinary installation. Maybe i did something wrong when I installed it. But I didn´t remove anything from the suggested items, just added. Hmmm...


What happens if you just type "perl"? (without options and script-files)

What are the permissions of your script-file?


If I just type "perl" I get the output of a blank line (as it should be as far as I know). The permissions of the file is 755...

About command invocation in (shell) scripts:
  if a shell reads a script file and the first to characters are
  then all following characters up to the next white space are a path to a program this script should be passed to, this program will be executed with exec().

This tells us that the (parents) shell PATH environment variable will not be needed if the word behind #! is a pathname.

What needs to be checked is:
  1. dos this command exist, and is it executable (it is, cl said)
  2. dos this command execute well if we pass the script to it, like:  /usr/bin/perl perlscript (it is, see question)
  3. are  #!  the very first characters in the file, no ctrl or any other unvisible characters before, and are there no such characters in the pathname

If above all works the problem must be the initial shell or the operating system. Things to check:
  1. do other interpreters start this way (awk, sh, csh, etc.)
  2. does it work with another interactive shell (sh, ksh, csh)
  3. are you limited in the number of processes
  4. does your shell allow exec()  (try with shell-builtin exec)

Is the directory with your script mounted over NFS? If so, could it be that you don't have execute permissions for that mount?

xilef, NFS cannot restrict mount points to special modes, just rw or ro. Or have you thought about a special NFS implementation?
In the UNIX world the mount point must have the x bits set, otherwise you even could not read anything there.

ahoffmann: I was thinking about the "noexec" mount option.

GNU's not UNIX, Linux is GNU
not so bad, xilef ;-))


Thank you all for your time och support.
I think I got something here........

I made a new script in the root of the filesystem.
The script had the same name as an ordinary textfile placed in another directory.
Then I executed the new script and got another error messages than before - "permission denied" . And in the error message the path was written to /usr/bin/filename.
Hmm... then I wrote ./scriptname and now it executed as it should.

Can it be something with the PATH order or is it something I just have to live with.


Yes, you have to add "." to your PATH (which is probably not a good idea for root).
You have not  .  in your PATH environment variable.


Do I have to place a script in a directory that is in the path?

I can execute script that is in for example /usr/bin, but not in a directory that is not in the path, (unless I had executed the script in a pathed directory before, it looks like the command is in some cache or something)

The PATH variable stores a list of directories where the shell will search for a command. When you put the dot on the PATH, you say the shell to search also on the current working directory.

You don't need to put the script on a directory appearing on the PATH environment variable, if you don't want to. Simply call it with the complete pathname. If you have the script on /tmp, so it is called /tmp/script, just type that name on the shell:


and that should work good. Sorry I did not realize yesterday but it was very simple. Your script was in a directory not in the path, so your shell won't find it when you called it with:


You should type


instead. Or


if it was on /tmp

Whe you called with "perl perlscript" perl was found because the perl binary is on the path!!! and perl will search for perlscript on the current working directory.



I see.

Thank you all.

Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.