Dear all,
I have a script which triggers a C program in it after initialising parameters.
Below is the sample
#! /bin/sh
. /my_data/environment
HOME=/home/execs/testing/
cd $HOME
compare $1 $2 X
exit $?
When I tried to run the script as sh -x my_script1.sh file1 file2 it is throwing 127 error.
Firstly, I would remove the space between #! and /bin/sh on the first line.
Can you post us the full error message? I'm assuming that compare is a function declared within /my_data/environment, but it would be good to know the content of that too.
I'm not sure where $PATH comes into your post though?
Thanks, in advance,
Robin
Robin,
That is a typo on the first line 
compare is the executable from a C program to compare files. environment file will have several variables defined and exported.
It does have export $PATH in it. And the $PATH variable has the "." in it.
I wonder why, the script is not looking in the current directory while I execute compare.
Thanks
Well, if you display the value of PATH before your call to the program, we can discuss it.
Can you also paste the full error message as the number 127 is not unique as an error message.
Robin
PATH=/my_data/execs:/universal/execs/:/newpath/configure/:.:/test_dir/:/bin/
This site has the message details
Does compare reside in any of those directories? Does it have "execute" permission?
the executable compare is present in HOME=/home/execs/testing/ . I switch directory before I run compare as well
If the executable is /home/execs/testing/compare, then you will either need to:-
In all cases, it would have to give you read & execute privilege, else the shell will ignore it when searching down the path or fail permissions if you give it as a full path.
Can you do a whence compare or which compare just before you call compare?
Perhaps the output from file /home/execs/testing/compare would help too.
Robin
Don't do that, ever. There's many reasons DOS-style path handling never became popular outside DOS.
Also, your (custom modified) $PATH looks VERY limited, will it find find, ls, grep, awk or even your shell?
With that $PATH, it wont find any of these, if they are at their regular locations. (edit: scratch that, just seen you had /bin, though, that might - but not granted - contain all the binaries required)
For the future, try:
PATH+=":/my_data/execs:/universal/execs/:/newpath/configure/:/test_dir/"
Note the + before the = !
AFAIK, its a bad habit to 'overwrite' $HOME with a custom location such as /home/execs/testing.
I'd recommend to set a new/other variable, and call it like, BASE or base or even more appropriate: WORKDIR=/home/execs/testing .
hth
sea is absolutely correct about not messing with HOME .
While += works in some shells, it doesn't work on some. (For example, /bin/sh on Solaris systems won't accept it.) The standard way to do it (supported by all shells based on Bourne shell syntax) would be:
PATH="$PATH:/my_data/execs:/universal/execs:/newpath/configure:/test_dir"
Note that the trailing slashes aren't needed; any element in the list of directories in PATH that isn't a directory will fail when attempting to add a command name to it anyway.
If you were writing a shell script (or a C program) that is intended to run with set-UJID or set-GID privileges and your program runs anything not using an absolute pathname to invoke it, then you should provide a PATH variable that is know to find the "desired" version of any programs invoked (not something that could spoof a "standard" utility and grab extended privileges for use later), but that is a much more complicated topic that clearly does not apply to this script.