Bash – Are Duplicate Entries in $PATH a Problem?

bashpath

I source bashrc's of few of my friends. So I end up having duplicate entries in my $PATH variable. I am not sure if that is the problem for commands taking long to start. How does $PATH internally work in bash? Does having more PATHS slow my start up time?

Best Answer

Having more entries in $PATH doesn't directly slow your startup, but it does slow each time you first run a particular command in a shell session (not every time you run the command, because bash maintains a cache). The slowdown is rarely perceptible unless you have a particularly slow filesystem (e.g. NFS, Samba or other network filesystem, or on Cygwin).

Duplicate entries are also a little annoying when you review your $PATH visually, you have to wade through more cruft.

It's easy enough to avoid adding duplicate entries.

case ":$PATH:" in
  *":$new_entry:"*) :;; # already there
  *) PATH="$new_entry:$PATH";; # or PATH="$PATH:$new_entry"
esac

Side note: sourcing someone else's shell script means executing code that he's written. In other words, you're giving your friends access to your account whenever they want.

Side note: .bashrc is not the right place to set $PATH or any other environment variable. Environment variables should be set in ~/.profile. See Which setup files should be used for setting up environment variables with bash?, Difference between .bashrc and .bash_profile.

Related Solutions

Bash – RVM + TMUX—Duplicate entries in $PATH

Solved by the following:

Placed a guard around my PATH manipulation code in .profile

if [ "$PATHS" != "true" ]; then
    export PATHS="true"
#Manipulate and export PATH over here
fi

Removed file-level guards around .bash_profile and .bashrc
IMPORTANT: RESTARTED the tmux server. (killall tmux) -- the manual indicates the server maintains its own environment, which it inherits from its parent shell. If config files change, tmux needs to start afresh.

Bash – Handling Duplicate Program Names

Your $PATH is searched sequentially. For example if echo $PATH shows /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin, each of those directories is searched in sequence for a given command (assuming the command isn't an alias or a shell builtin).

If you want to override specific binaries on a per-user basis (or you just don't have access to override for other users than yourself), I would recommend creating a bin directory in your home directory, and then prefixing your PATH variable with that directory.

Like so:

$ cd ~
$ pwd
/home/joe
$ mkdir bin
$ echo "$PATH"
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
$ echo 'export PATH="$HOME/bin:$PATH"' >> .bash_profile

Then source .bash_profile so the new PATH definition will take effect (or just log out and log in, or restart your terminal emulator).

$ source .bash_profile
$ echo "$PATH"
/home/joe/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Now, any executable files you put in /home/joe/bin/ will take precedence over system binaries and executables.

Note that if you do have system access and the overrides should apply to all users, the preferred place to put override executables is /usr/local/bin, which is intended for this purpose. In fact often /usr/local/bin is already the first directory in $PATH specifically to allow this.

Best Answer

Related Solutions

Bash – RVM + TMUX—Duplicate entries in $PATH

Bash – Handling Duplicate Program Names

Related Question