[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 312
  • Last Modified:

Easy question !?

Hi

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.

Greatful
Claes Lindvall
Sweden
0
cl071997
Asked:
cl071997
  • 9
  • 8
  • 5
  • +1
1 Solution
 
ahoffmannCommented:
what's the error message?
0
 
cl071997Author Commented:
The error message is "command not found"...
The perl directory is included in the path ( /usr/bin/perl).

/Claes
0
 
ahoffmannCommented:
check with od -c if these are realy the first chars in your script:
    #!/usr/bin/perl

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

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
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.

/Claes
0
 
ahoffmannCommented:
which shell are you using? try another one (bash, tcsh, etc.)
0
 
cl071997Author Commented:
Sorry, I´m already using bash, and I even tried with "sh"...
Any other ideas...?

/CL


0
 
ahoffmannCommented:
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  ?
0
 
xilefCommented:
Can you give us the output of "ls -l /usr/bin/perl"?

0
 
pablocostaCommented:
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
pablo
pablocosta@iname.com
0
 
cl071997Author Commented:
Here it comes
-rwxr-xr-x   2 root     root       504764 Apr 22  1997 perl

/CL
0
 
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...

/CL

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

What are the permissions of your script-file?

0
 
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...


/CL
0
 
ahoffmannCommented:
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)

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

0
 
ahoffmannCommented:
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.
0
 
xilefCommented:
ahoffmann: I was thinking about the "noexec" mount option.

0
 
ahoffmannCommented:
GNU's not UNIX, Linux is GNU
not so bad, xilef ;-))
0
 
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.

/CL
0
 
xilefCommented:
Yes, you have to add "." to your PATH (which is probably not a good idea for root).
0
 
ahoffmannCommented:
You have not  .  in your PATH environment variable.
0
 
cl071997Author Commented:
Alright.
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)

/CL
0
 
pablocostaCommented:
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:

/tmp/script

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:

perlscript

You should type

/perlscript

instead. Or

/tmp/perlscript

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.

Pablo
pablocosta@iname.com
0
 
cl071997Author Commented:
I see.

Thank you all.

/CL
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 9
  • 8
  • 5
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now