I've always been hesitant to include any user-defined directory in my PATH environment variable or put custom scripts in an already included directory.

The reason for this is that I don't know how to avoid an (admittedly) unlikely edge case, i.e. a binary calling an external program which happens to have the same name as one of my custom scripts without the wanted binary existing on the machine and therefore the program actually calling my custom script instead which can only lead to trouble.

This is somewhat similar to shadowing a binary with a custom script of the same name like it's usually done with wrapper scripts. In this case, however, the program in question doesn't exist on the machine (only a custom script with the same name) and thus the position of the custom script location in the PATH variable doesn't matter at all either.

Is there any way to avoid such a situation other than simply not storing custom scripts in directories used in the PATH variable? The only possibility that comes to my mind is always using absolute paths to call custom scripts instead.

  • 2
    Yes, essential system PATH directories come first for starters. – Rui F Ribeiro Feb 10 '18 at 15:51
  • Use aliases if you don’t want to modify your path to include e.g. ~/bin. This way, only those binaries and scripts you add to your shellrc are in environment. Use custom names. – user2497 Feb 10 '18 at 17:43
  • My preference: “production” programs, apps, binaries should not depend on environment variables like PATH. If the user can access the program, eg with an empty environment, then the program should work. Ideally the program should be able to figure out dependencies by determining where it, the program, is installed. – Krazy Glew Feb 15 '18 at 15:35

Three solutions:

  1. Always call your custom scripts with an absolute path, as you yourself suggest, without modifying $PATH.

    This will ensure that you call your own scripts when you know you want to, and that your scripts do not accidentally "shadow" any other utility.

  2. Make sure that the path(s) to your custom scripts are located towards the end of $PATH, after the paths to standard directories and directories that hold 3rd-party software.

    This has the downside that if you do happen to have a script with the same name as another utility, you would call that utility instead of your own script. This is the reverse problem of the one you're concerned about.

  3. Simply make sure that your scripts have unique names, then do as in the previous point.

    System utilities seldom (and standard utilities never), for example, use .sh as a file name suffix. You may also/alternatively consider establishing a "namespace" such as a wally- prefix to your own scripts (wally-backup.sh or wally-getmail).

In general, you should know what names standard Unix utilities have and avoid them (test, for example, is a bad name for a custom utility). A list of standard utility names is available here. Likewise, the names of special built-in utilities should not be used for custom scripts. These are listed at the end of this link.

If you modify your $PATH, modify it privately, i.e. only for the unprivileged user that you log in as. Don't modify it system-wide, unless you are a system administrator on a multi-user system and your scripts are actually to be used by other people (and it would be bothersome for them to modify their own $PATH for one reason or another). If you modify your system's $PATH, make absolutely sure that the "shadowing issue" does not happen, or basic system functionality may be compromised, depending on where that $PATH may be used.

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.