When running a sh file in linux, why do I have to run ./name.sh?

I 开发者_Go百科have a file called x.sh that I want to execute. If I run:

x.sh

then I get:

x.sh: command not found

If I run:

./x.sh

then it runs correctly. Why do I have to type in ./ first?

Because the current directory is not into the PATH environment variable by default, and executables without a path qualification are searched only inside the directory specified by PATH. You can change this behavior by adding . to the end of PATH, but it's not common practice, you'll just get used to this UNIXism.

The idea behind this is that, if executables were searched first inside the current directory, a malicious user could put inside his home directory an executable named e.g. ls or grep or some other commonly used command, tricking the administrator to use it, maybe with superuser powers. On the other hand, this problem is not much felt if you put . at the end of PATH, since in that case the system directories are searched first.

But: our malicious user could still create his dangerous scripts named as common typos of often used commands, e.g. sl for ls (protip: bind it to Steam Locomotive and you won't be tricked anyway :D).

So you see that it's still better to be safe that, if you type an executable name without a path qualification, you are sure you're running something from system directories (and thus supposedly safe).

Because the current directory is normally not included in the default PATH, for security reasons: by NOT looking in the current directory all kinds of nastiness that could be caused by planting a malicious program with the name of a legitimate utility can be avoided. As an example, imagine someone manages to plant a script called ls in your directory, and that script executes rm *.

If you wish to include the current directory in your path, and you're using bash as your default shell, you can add the path via your ~/.bashrc file.

export PATH=$PATH:.

Based on the explanation above, the risk posed by rogue programs is reduced by looking in . last, so all well known legitimate programs will be found before . is checked.

You could also modify the systemwide settings via /etc/profile but that's probably not a good idea.

Because current directory is not in PATH (unlike cmd in Windows). It is a security feature so that malicious scripts in your current directory are not accidentally run.

Though it is not advisable, to satisfy curiosity, you can add . to the PATH and then you will see that x.sh will work.

If you don't explicitly specify a directory then the shell searches through the directories listed in your $PATH for the named executable. If your $PATH does not include . then the current directory is not searched.

$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

This is on purpose. If the current directory were searched then the command you type could potentially change based on what directory you're in. This would allow a malicious user to place a binary named ls or cp into directories you frequent and trick you into running a different program.

$ cat /tmp/ls
rm -rf ~/*
$ cd /tmp
$ ls
*kaboom*

I strongly recommend you not add . to your $PATH. You will quickly get used to typing ./, it's no big deal.

You can't execute your file by typing simply x.sh because the present working directory isn't in your $PATH. To see your present working directory, type

$ pwd

To see your $PATH, type

$ echo $PATH

To add the current directory to your $PATH for this session, type

$ PATH=$PATH:.

To add it permanently, edit the file .profile in your home directory.