Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can't think of any reason why adding ./bin to my PATH environment would be a very bad idea.

I usually create bin folders in my projects that I am working in and I hate doing bin/command, it would be nice, to have command be picked up by bash as long as I am in the directory with a bin folder and that bin folder contains a command executable.

I need convincing :D

share|improve this question
up vote 4 down vote accepted

The $HOME/bin, . and ./bin are usually looked as a security risk.

for the $HOME/bin its the problem of some "cracker" push some script (say a script named nano) to there and waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever, the command isnt important, its the payload it can execute)

for . and ./bin is still the same problem, added a extra: working on the wrong directory.

If those ./bin/command are in different directories instead of /usr/local/bin (the preferred solution for new, local scripts), its because they do different things... what if you run the incorrect one?

If you name your commands the same way (lets call then update, commit, cleanup, etc) you may be working on a directory, then you get one phone call and change to another for a quick check. After hangup, your brain will try to resume what you were doing and most of the times will forget that quick "cd" you made (specially if everything on the screen seems to point to the correct directory) and finish running a command on the wrong directory (say that cleanup script that erases all your month work).

It might look a innocent mistake, but they happen everyday to many people! :)

a good workaround (or better solution) is to use alias:

alias proj1-cleanup=/srv/proj1/bin/cleanup

and add on the script the correct cd to make sure it runs on the correct directory.

This way play with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone crack your browser to create a $HOME/bin/ls file or some local user creates a bin/ls file on any directory, those will never be executed, as your path still points to the correct commands.

but hey, its a personal choice, you are the one that knows what are your local risks and what the commands do.

share|improve this answer
I never thought of the sudo nano $file catch, awesome work higuita – whoami Mar 11 '13 at 0:34
Yes, if you do something like that it must come at the end (but beware of typos like sl for ls). And leave it open as in ./bin is much worse than $HOME/bin or a fixed set of $HOME/$SOMEPROJECT/bin, as a miscreant has to crack your account for the last ones (and then sudo protection is more or less moot), while e.g. /tmp/bin is accessible to anybody. – vonbrand Mar 11 '13 at 2:05
If someone else would have gained access to your account, and is able to push scripts to $HOME/bin, then they are most likely able to modify $HOME/{.alias,.profile,.bashrc}. In this scenario you are screwed anyway. so I wouldn't say adding $HOME/bin to path adds any security risk. – Kotte Mar 11 '13 at 9:33

On Ubuntu at least, this is part of the default user profile:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then

I don't think it's a problem, but since it's user-writable and could transparently intercept commands, people can be nervous about it. Obviously this is a safer than ./bin, however.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.