It looks like when adding a directory into $PATH, its subdirectories are not added recursively. So can I do that? Or is there a reason why this is not supported?

  • 5
    Why on earth do you need that? – alex Jul 31 '11 at 7:35
  • 10
    @alex: Why do you think there is no need? – Tim Jul 31 '11 at 11:16
  • 4
    @Tim the reason it's not "generally" supported is it's a security risk and generally not needed. If you recursively add directories to your path who knows what might get stuck in there... makes it a lot harder to audit. – xenoterracide Jul 31 '11 at 14:44
  • 4
    @Tim: it's a really surprising and unusual thing to want, that's why. – alex Jul 31 '11 at 15:21
  • 8
    @alex what about for subdirectories in the bin directory? i'd love to organize scripts in directories in the bin folder. – Andy Jul 14 '14 at 15:36

Add them recursively using find like so:

PATH=$PATH$( find $HOME/scripts/ -type d -printf ":%p" )

WARNING: As mentioned in the comments to the question this isn't encouraged as it poses a security risk because there is no guarantee that executable files in the directories added aren't malicious.

It's probably a better solution to follow Gilles' answer and use stow

  • 6
    Warning: This answer is technically correct but as alex and xenoterracide note this is a crazy-insecure thing to do and you should definitely think twice before actually using this. – Caleb Aug 1 '11 at 9:56
  • 2
    Please add a warning to your answer about why this is not a good, safe thing to do in practice. – Caleb Aug 1 '11 at 9:58
  • 3
    I wouldn't consider it particularly dangerous; adding random directories to $PATH is dangerous, but adding subdirectories isn't markedly worse. But it's usually useless, and possibly inefficient (and might even throw you onto environment size limits sometimes). – Gilles Aug 2 '11 at 22:12
  • 3
    @Caleb: crazy perhaps, but why insecure? If someone has access to add malicious executable files in subdirs, he could also add them to the parent dir (ie, ~/bin or ~/scripts), so their security is the same. – MestreLion Dec 31 '15 at 12:14
  • 2
    Security risk if you work in an environment where random people can add malicious files to your ~/scripts. I don't and neither should anyone else – oseiskar Jul 8 '16 at 12:53

The usual unix directory structure has application files sorted into directories by kind: bin for executables, lib for libraries, doc for documentation and so on. That's when they are installed in separate directories; often applications are grouped into a few directories (hence many systems have just three directories in $PATH: /usr/local/bin, /usr/bin and /bin). It is rare to have both executable files and subdirectories inside a directory, so there's no demand for including a directory's subdirectories in $PATH.

What might occasionally be useful is to include all the bin subdirectories of subdirectories of a given directory in $PATH:

for d in /opt/*/bin; do PATH="$PATH:$d"; done

However, this is rarely done. The usual method when executables in non-standard directories are to be in $PATH is to make symbolic links in a directory in the path such as /usr/local/bin. The stow utility (or xstow) can be useful in that regard.


One reason that this is not supported is because the bin/ (and similar) directories use symbolic links to point to the specific directories where actual executables for programs are installed.

So, if your $PATH includes /usr/local/bin (which it most likely does) that folder is full of symbolic links (like ruby) which point to the specific directory where the code to run ruby is found (like ../Cellar/ruby/2.1.3/bin/ruby).

This is why you don't have to specify each executable's folder in your $PATH; the symbolic links customarily found in bin/ type directories handle that for you.

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.