HI all
can anyone tell why u use ./ in exicuting any exicutable in linux

eg:
./a.out
./configure

but why ./ ??

./ denotes your current directory. If you try to run, lets say, configure, without the './' your system will look for the executable in the directories specified in your $PATH variable.

. - current directory (/home/user/secret)
.. - one level higher (/home/user/)

So, assuming you have a program called fantastic_app in /home/user/programs/, you can run it either by cd'ing into /home/user/programs/ and calling ./fantastic_app (works only when you're in the same directory the app is in) or with /home/user/programs/fantastic_app (works regardless of your current dir).

Thank you so much.....

but whats this $PATH variable....????
even i experianced the problem while writing a make file.....

i mistakely used PATH as a userdefined variable.... but then it gave un predicatable results

By convention, the environmental variables are in all caps. You can see a complete list by entering the "env" command. To see only the value of PATH, enter "echo $PATH" (no quotes). PATH contains a list of directories that are searched when you enter an executable command.

PATH is a list of directories the shell will search for the named executable. For the root user, PATH would include directories such as /bin, /sbin, /usr/bin, /usr/sbin. The normal user may not have those directories in his PATH.

To see what is in your path, in a console give the command: echo $PATH.

To add to your PATH, give the command (as user if you want to change the users PATH): PATH=$PATH:/sbin. That would add /sbin to your user's PATH.

Then finish the addition to your PATH with the command: export PATH.

Or, do it all in one line: export PATH=$PATH:/sbin

By the way, I've seen people add . to their $PATH. Rarely, but still. Is there any real reason why that should NOT be done? I don't think I've seen any distro have that out of the box.

Don't put . in your path, especially if when running as root. Here is a scenario to explain why:

Say a malicious user creates an executable script that does some serious damage, like recursively deleting all files on /. He names this file ls and puts it on as many directories as he has write access to.

Sometime when you are signed on as root, with . in your path, you navigate to one of those directories and type ls to see what's in it. The rogue script is executed instead of the real ls. Since you are root, you have the power to execute the killer lines of the script, and your system is destroyed.

There are also consequences of running with . in the path as a normal user, although the damage may not be system-wide. But it is still in your best interest not to leave yourself exposed. Just get in the habit of using the ./ to run local scripts.

Alright, thanks for clearing that one up!

Are the directories in $PATH checked in the same order they're listed? If so, adding . to the end should (theoretically) be safe - before the shell reaches the current directory and runs the evil script (which would have to have the same name as an often used program for the 'trap' to make sense) it should find the real application in one of the previous directories (to which the malicious user has no write access.. and if he had, the attacker would probably just replace the real application with the evil one).

Just wondering, just wondering..

You make a good point. Yes, I believe the paths are searched in order. However there are still some pitfalls, like aliases and internal commands. An internal command is built in with no executable file involved. For your own education, check the manuals, tutorials, etc. on the order of preference for external, internal, and alias commands.

Also, putting . at the end may defeat part of your purpose for using it at all. If you are developing a script, you may have a production version in /usr/bin and one in your ~ directory. For testing you want to use your own version, but without ./ you would never see it because the production version would pop up instead.

HTH

thanks all..
i got the answer...
when we do ./a.out a child is forked and using execev the address space of new child is replaced with a.out...............

Another danger would be a cracker adding a prog with a common misspelling of a cmd, much like the website name hijackers.

Totally agree. You'll get used to it quickly, and you'll be compatible with just about any standard *nix box.