Hi,
I am really sorry for this question but still i am confused.
I have shell script called sample.sh
I can execute only with the combination of ./sample.sh
Is ./ really necessary ? Is it something related with $HOME or $PATH variable.
Why and How can i resolve this case ?
Regards,
Nantha
Hello Nandy,
You are right on your thinking. The ./ before a script states that it is the one in the current directory to be run. If you just try to run it without any path at all then the shell (gives you the command line) will search each directory in turn down the definition of $PATH
You can adjust the value by adding this to your profile:-
PATH=$PATH:.
The colon : is the separator between entries and the dot . states the current directory.
This will mean that as you change directory, the scripts in the current directory become automatically available (subject to permission) and those you have left behind are not. If you want to always have your home directory looked at, you can add:-
PATH=$PATH:$HOME
or a combination of the two even:-
PATH=$PATH:.:$HOME
The order is important, so it needs a little thinking about on how you want to set it for your environment.
As to which profile you add it in to, well that depends on your shell.
Can you post the output from:-
echo $SHELL
ps -f
I hope that this helps,
Robin
here is the short version: yes, it is necessary. Yes, it is related to the PATH variable. Yes, you could "resolve" that. No, you shouldn't do it anyway.
OK, here the same in long form:
In principle, every "command" you issue is an execution of a binary file: you probably have used the command "ls -l /some/place". This ultimately has called the binary "/usr/bin/ls" with the option "-l" and the argument "/some/place". Binaries can only be called giving the full path name of where they are. To stick with the above example "/usr/bin/ls". The reason is that there might be more than one binary named "ls" in different places. There would be no way to decide between "/usr/bin/ls" and "/some/other/place/ls".
I see you wondering now "why did ls -l work, then?" The question is legitimate. This is where the PATH variable enters the picture. "PATH" contains a list (separated by ":") of directories which are tried (in the same order as they are set in the variable). Whenever you enter a command the system cannot make sense of (like "ls" instead of "/usr/bin/ls") these pathes are tried to be prepended to the command and the system looks if it can find it there. Here is an example:
PATH="/usr/bin:/usr/sbin:$HOME/bin"
# command
The system - failing to understand "command" - will now do the following:
It is indeed possible to add the current directory to the path and make every executable in the current directory accessible by adding "." to the PATH:
PATH=/usr/bin:<and-so-on>:.
BUT: this is considered a very bad idea and so with a reason! If you are interested in details here is a thread obut it. In short making executables in any arbitrary directory ("." is where are right now, which can be everywhere) is a security problem and you are maybe not executing what you think you do (but something else instead).
Here is a better way: create a "bin" directory in your HOME-directory, then add this directory to your PATH. "cd" without any parameter will take you to your homedir, regardless of "$HOME" being set or not, "~" is short for "my home directory":
# cd
# mkdir ./bin
# PATH="${PATH}:~/bin" ; export PATH
If you want to have your PATH variable modified permanently put the last line into the file ~/.kshrc or whereever the variable "ENV" points to.
Whenever you have executable files put them into this directory and you can execute them without adding the path at all.
I hope this helps.
bakunin