6

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?

  • 1
    Depending on how the processing of PATH is processed, the time complexity will be ether O(n) or O(log n), where n is number of entries in the PATH. With the symlink solution the time complexity will be O(1). – ctrl-alt-delor Jan 22 '17 at 11:53
  • @richard: Yes, I've changed my opinion, and now I believe a symlink approach is wiser, although I'm still researching symlink stow-like solutions. – cesss Jan 23 '17 at 22:07
6

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 $PATH would impose a serious performance issues if using a sensible shell.

For an alternative solution, have a look at GNU Stow.

  • Thanks a lot. I'm not yet sure about what will be best in the end. But I've changed my view, and now I believe it's wiser to take a symbolic links approach rather than a huge $PATH. However, I don't like that GNU Stow requires Perl, so I'm researching other alternatives. – cesss Jan 23 '17 at 22:05
4

The $PATH solution is heavily dependent on $PATH being successfully set on boot, making the whole setup fail if the environment configuration is damaged/deleted somehow.

The symlink method is more robust since it is mostly self-reliant, although a bit more complex to set up.

The GNU Stow project and nixOS are two ways of using the symlink method that you can use or examine for insight into how it works in practice.

  • Actually, I think the $PATH solution is more robust, because it's easier to be robustly controlled by shell scripts, while symlinks are more prone to require cleaning at some point. However, I think the symlink approach would be preferred because of performance. Also, maybe I could experience issues at some point if I use a $PATH longer than most users do. – cesss Jan 23 '17 at 22:11

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.