Easy question !?


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
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

what's the error message?
cl071997Author Commented:
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).
Price Your IT Services for Profit

Managed service contracts are great - when they're making you money. Yes, you’re getting paid monthly, but is it actually profitable? Learn to calculate your hourly overhead burden so you can master your IT services pricing strategy.

cl071997Author Commented:
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.)
cl071997Author Commented:
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"?

well you talk'bout slakware. maybe you upgraded your linux?

the possible causes I think of are that:
- the /usr/bin/perl is a soft link to another file which might not exist. Maybe the 'pointed' file was there but now it isn't now, and the perl binary is on another place of your path.
- the /usr/bin/perl binary have wrong mode (not executable)
- one of the directories over the binary have wrong modes.

Please check that:

- the /usr/bin/perl is a file (or a soft link pointing to a binary)
    _   file /usr/bin/perl   _

- how many copies of 'perl' you have
    _  find / | grep perl | less

Then take a look at your path from the openwindows shell and think which copy (or link) of 'perl' found on previous step is being called when you type 'perl <perlscript>', and think if you want to modify your path to match the perl binary or the perl script to point to another copy of perl

hope this helps

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cl071997Author Commented:
Here it comes
-rwxr-xr-x   2 root     root       504764 Apr 22  1997 perl

cl071997Author Commented:
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?

cl071997Author Commented:
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 ;-))
cl071997Author Commented:
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.
cl071997Author Commented:
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.

cl071997Author Commented:
I see.

Thank you all.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.