The feature I'd really need is to be able to create "virtual directories" by merging a collection of real directories (so that your /usr/bin is actually a virtual thing that points to an array of directories).
However, this feature, although available in some operating systems, is not widespread, and you cannot expect you'll have it supported in the OS you'll be using next year, for example.
For the moment, I'm using the $PATH variable as a workaround, storing in it the whole collection of directories I wish to "merge" (and plan to use others, like $MANPATH, for manual pages, as well as analogous equivalents for libraries).
I'm not hitting any performance issue for the moment, as the collection of "merged directories" is not big, but I'm wondering if I could experience issues in case the number arrives in the future to hundreds of directories (I don't know if such a big number will happen, though).
The expected number of "merged" directories I'm guessing for the foreseeable future is about 40 to 50.
The workarounds I found for this feature are mainly based in managing symbolic links, thus effectively mirroring all files from all merged directories as symbolic links pointing to them from the "unified" directory. However, such approach looks like overwhelming complexity to me. It doesn't look like a tidy, clean, solution.
Do you think I could go on with the $PATH approach, or should I stop, reconsider, and study other options?
Best Answer
The shell usually caches the information about where external utilities are found, which means that it really only needs to do a single lookup for each non-cached utility.
I would not expect that having a long
$PATHwould impose a serious performance issues if using a sensible shell.For an alternative solution, have a look at GNU Stow.