Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
Code:
export PATH=".:$PATH"
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)
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...
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)
Code:
export PATH=".:$PATH"
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)
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)
Last edited by r3sistance; 10-28-2009 at 12:17 AM.
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.
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
Code:
cd /usr/local/bin
ln -s <pathtoprogram2>/program2.sh program2.sh
/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.
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 scripts
Code:
export PATH="$PATH:$(pwd)"
I use ./myscript.sh; the ./ prefix is not onerous, especially using command recall.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.