Hi there,
There is something which has always puzzled me regarding scripts and I wonder if anyone would kindly take the time to explain this.
I have a script called example.script I make this executable by chmod u+x example.script. So why does the script only execute when I type ./script.example and not when I type in just the script name (even when I am in the script's home directory) ? Does bash not look in in the current directory first prior to searching the $Path for the said executable ?
I am sure that on some unix systems I could run a script ( if it was in my current directory) just by typing its name even though its location was not in the $PATH .

Thanks again,
Uncle.

It is because the path "." isn't present. Doing so would be a security risk. Especially if your /tmp directory isn't on its own partition with the noexec option.

I think in some shells you may be right. For example I *think* the Solaris machines I sometimes use allow that. But in Bash I've always found the ./ necessary for items that aren't in $PATH. There may be a way to change this , but it would probably be more effort than just typing ./ when you want to run a script.

In many distributions, $HOME/bin is in path, so perhaps storing them there will add this functionality for you. If not, you can add it yourself in $HOME/.bashrc by adding (or maybe creating the file with)

export PATH=$HOME/bin:$PATH

mmatt

Thanks for the explanation guys. MMatt I was using Solaris a long time ago and that is from where this quirk probably arose.
Jschiwal, I remember reading about this in a Unix Security Checklist. Could you kindly explain this ?? What would be the nightmare scenario ?

Thanks again !

Uncle

The /tmp directory is world writable. It has the sticky bit set so that one user can't delete another users files. Imagine that the /tmp directory is getting full and you enter it as root to delete files there. If a regular user created a program by the same name as "ls" or "rm" that would also install a root kit, then you would be toast just from listing the files. The fake ls command might call the real one so you wouldn't notice, and might in the background install it's own version's of "ls" and "ps" to hide it's presence. Another trick is to name a program after a common misspelling like cd.. .
If you had "." in your path it might run the command from the local directory by mistake. This may even be done by a background script if the CWD is /tmp.

I read where a company was touting their system as super-secure at a trade show. A kid saw that "." was in the PATH and guessed correctly that that was the case for ROOT as well. He wrote something in /tmp and then came back later asking the salesman a question that required the salesman to list files in /tmp. The salesman did this as root. The kid wasn't malicious in what he wrote in the ten seconds or so he was on the machine. I think it simply cleared the screen and put up a false message about formatting the hard drive.

This may also be the oldest hack on Unix as well. If you used a machine and "." was in the path, it was probably added by a lazy admin for convenience. I bet that the root users PATH variable wasn't like that however. Even so, if as a regular user you cd to any world writable directory, or even if a GUI program launches with a world writable directory as it's CWD, you could have your own files trashed. An OS is easy to replace by reinstalling. Your data might not be.

Many thanks jschiwal. You have made things crystal clear !!!

All good wishes,
Uncle-C

Thanks jschiwal, I've learnt my something new for the day.