thanks for the tip.

Does ./program2.sh work while in the directory that program2.sh exists in?

Yes

If you want the shell to search the current directory for the executable before all the other directories (this is useful if you want to replace a system command -- for example, you could write a script called ls and it would be run instead of /bin/ls)If you want the shell to search the current directory for the executable after all the other directories (safer -- in case you accidentally create an executable with the same name as an existing executable and run it accidentally with unexpected effects)Not recommended to have . in root's $PATH.

If this is a script you want to be able to call from anywhere, one possibility is the following command

ln /bin/program2 <pathtoprogram2>/program2.sh

This would place a Symbolic link in /bin to your script, this is just if you wanted to be able to run it from anywhere, personally I wouldn't advise this for most generallised scripts however. You could add a directory to path for little scripts like that... as './script' works however, it makes it appear strange that 'sh script' doesn't work...

I didnt get the last line.why?

Any way i think i have got Answer to my question.

I wanted to run my script in vi using :!<program-name> syntax
I have exported path to "$PATH:."
I m logging into system using root and now able to execute the file by just using its name.

Is there anything wrong in above mentioned method?
will it impact system working in any wrong manner?

having . in your path will mean you could possible get into situtations where commands in current directory will override those in other directories, assume for a moment you have a script file called cd that you use to mount the cd-rom drive, if you had . in path and you went to use the cd(change directory) command, it wouldn't work as the script file to mount a cd-rom could potentially take priority, it's not an end game situtation, you could just rename the script or remove it...

This was just an example, I am not sure if you can do this with cd as cd is actually built into bash... however not many things are (IE ls for example comes from /bin/ls)

I have exported path as "$PATH:." and not ".:$PATH" so i think cd .. will get you to parent directory rather than mounting a cd-rom drive as it will first check the path and then the current directory.
However i m a newbie and cant confirm on the same.Any expert please suggest if i m wrong.

Yes -- you've got it right.

According to The Linux Documentation Project's security HOWTO you should never have . in root's $PATH. You could follow that advice and still have the convenience you want by following r3sistance's advice although I would change it slightly to/usr/local/bin is more appropriate for locally written programs (see the Linux Filesystem Hierarchy); a symbolic link (created by the -s option on ln) will work even if the target is on another file system; the existing file must be given before the symbolic link name; it's more transparent if the symbolic link name is the same as the file it links to.

But then i have to make symbolic links for every program i write .

I usually add . in path when i m troubleshooting some scripts to make their execution simpler.
Please explain whats the harm in putting . in path variable.

The usual explanation is "Including the current working directory '.' (dot) or other writeable directory in root's executable path makes it likely that an attacker can gain superuser access by forcing an administrator operating as root to execute a Trojan horse program". This is unlikely to happen on a system used only by yourself when the . directory comes at the end of $PATH. Still safer not to do it. Alternatively you could put the current directory in $PATH temporarily when developing scriptsI use ./myscript.sh; the ./ prefix is not onerous, especially using command recall.