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


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

For the $HOME/bin it's the problem of some "cracker" pushing some script (say a script named nano) to that directory, then it waits until you run something like sudo nano /etc/hosts to gain instant root access (change the nano to vi, emacs, whatever; the command isn't important, it's the payload it can execute).

For . and ./bin, it is still the same problem: adding an extra program working from the wrong directory.

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

If you name your commands the same way (let's 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 (particularly 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 an innocent mistake, but they happen every day 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, playing with the $HOME/.alias to add the various scripts you need, you have different commands to do the different things, and even if someone cracks 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, it's a personal choice; you are the one that knows what your local risks are and what the commands do.

  • I never thought of the sudo nano $file catch, awesome work higuita – whoami Mar 11 '13 at 0:34
  • 1
    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
  • 6
    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
  • If the ./bin or $HOME/bin is always after any standard locations like /usr/bin and /usr/local/bin, then wouldn't the example you gave of some would-be cracker putting a malicious file there not work as they intended? – Mark Feb 27 at 17:50
  • @Mark not everyone puts the $HOME/bin after the standard bin paths, for several reasons, but even if in the last search path, simple things like sl (instead of ls), xs or vf (bad finger position on keyboard) instead of cd, rsymc instead of rsync, cd.. instead of cd .., etc. Just create hundred of common typos in the $home/bin and sooner or later you will do some typo. How many times do you do a ls $HOME/bin to see what is there?! – higuita Feb 28 at 23:36

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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