47

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?

12
  • 5
    Why on earth do you need that? – alex Jul 31 '11 at 7:35
  • 17
    @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
  • 10
    @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
29

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
  • 7
    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 'SO- stop being evil' Aug 2 '11 at 22:12
  • 4
    @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
31

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.

4

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.

3

In zsh, $PATH can be appended as an array. You can use shell globbing to add multiple subdirectories to the $PATH array.

Example:

In .zshrc:

typeset -U PATH path
BINPATH="$HOME/bin"
path+=("$BINPATH" "${BINPATH}"/*/)
export PATH

This will append all subdirectories of $BINPATH to the $PATH array.

1
  • Note if you have any symbolic links in the $BINPATH the sub-directories will not be included. Creating a symbolic link in $HOME/bin such as ln -s $HOME/Apps only the $HOME/Apps base directory will be added to the path. None of the sub-directories in $HOME/Apps/ will be added. This surprised me as the /*/ implies this should work but doesn't. – RyanNerd Feb 14 at 18:42
1

Try this way:
export PATH="$PATH:$(du "~/scripts/" | cut -f2 | tr '\n' ':' | sed 's/:*$//')"
This will add ~/scripts itself along with all its subdirectories into $PATH
Explanation:
- du will display all the subdirectories info each line
- cut -f2 will extract the second column, i.e., the names of the subdirectories
- tr '\n' ':' will change each link break into a colon. This will join all lines into a single line and the subdirectories are delimited by a colon
- sed 's/:*$//' will remove the last colon

1
  • while we are making a clear mention of scripts, that in theory should be small files, using a heavy tool like du (short for disk usage), is a poor approach; as you do pipe, cut, tr and sed, you could also start from something built to be fast and do not "be sure" about file size as the info will be tossed as ls that was built to list files; – Thiago Conrado Nov 21 '20 at 23:51
0

The answers didn't work for me on Mac OS, so I found a way that works:

export PATH=$PATH:$(find $HOME/apps -type d -maxdepth 1 | paste -sd ":" -)

I hope it helps!

Note: this also includes the folder itself.

0

@lucasls way is great and works really well, though that listed way does only work for Mac, it seems. For Linux (At least on Pop_OS 20.10 using zsh) you have to slightly rearrange things in order for it to work.

export PATH=$PATH:$(find $HOME/apps -maxdepth 1 -type d | paste -sd ":" -)

The -maxdepth is a global option and is required to be listed before the -type argument, otherwise, you end up with an error message stating as such.

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.