Month: September 2013

I’ve recently being doing a cleanup of my dotfiles (more on that later). In the process I commented out all of the “export PATH=...” statements in the profile and rc files in my home directory, but my path was still getting set to this:

/bin:/usr/bin:/sbin:/usr/sbin:usr/local/bin:/usr/local/git/bin:/usr/X11/bin

There are three problems with this:

1. I’d prefer my /usr/local/bin to be first
2. I don’t want/need either of those git/x11 paths
3. I don’t like not understanding where things are getting set!

I eventually worked out that it came down to some files in my /etc directory :

#/etc/paths
/bin
/usr/bin
/sbin
/usr/sbin
/usr/local/bin

#/etc/paths.d/git
/usr/local/git/bin

#/etc/paths.d/x11
/usr/X11/bin

The paths.d method actually makes a lot of sense for a certain kind of application: it’s a nice clean way of adding bin files to the path nice and early (before any local modifications to the path).

Here’s the full order in which my paths were getting loaded in (I’m using zshell):

/etc/profile
/etc/profile.d/*
~/.zshrc (which loads in ~/.profile)

Apparently /etc/profile can come into play as well, but mine doesn’t set the path so I’m not sure what the ordering is. Indeed it looks like /etc can have it’s own set of shell-specific configs as well (mine seems to have a default bashrc), but that’s a whole other ballgame.

My solution

Now that I properly understand how my path is getting generated, I’m comfortable setting it from scratch in my local profile:

#~/.profile
export PATH=/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin

I prefer to have /usr/local/bin first, because this means that I can install things in /usr/local and symlink them into /usr/local/bin without conflicting with any old versions which came bundled with the operating system (and thus live in /usr/bin)

I could have achieved the same effect by editing /etc/paths, but I’d like to try and make my dotfiles as portable as possible

The following posts really helped me understand all this:

http://craiccomputing.blogspot.co.uk/2010/10/etcpathsd-as-way-to-configure-paths-in.html

http://superuser.com/questions/69130/where-does-path-get-set-in-os-x-10-6-snow-leopard

I’ve just been cleaning up my zshell config files. I noticed that the following lines were at the end of both my .zshrc and .zprofile files:

# Add RVM to PATH for scripting
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

I’m not sure how I got into that situation, but this duplication was an itch which had to be scratched.

Removing this from .zshrc gives the following error when trying to use rvm:

Warning! PATH is not properly set up, '/Users/duncanstuart/.rvm/gems/ruby-2.0.0-p247/bin' is not at first place,
usually this is caused by shell initialization files - check them for 'PATH=...' entries,
it might also help to re-add RVM to your dotfiles: 'rvm get stable --auto-dotfiles',
to fix temporarily in this shell session run: 'rvm use ruby-2.0.0-p247'.

This is fair enough: for reasons I don’t fully understand, rvm needs a bunch of paths to be at the very beginning of PATH – that’s why the lines in question need to be at the end of the .zshrc file. Looking at my path (echo $PATH), those paths are in the middle somewhere – presumably being added by .zprofile. No good.

On the other hand, removing this from .zprofile gave me a couple of  errors from rvm on opening a new terminal:

/Users/duncanstuart/.rvm/scripts/initialize:42: __rvm_cleanse_variables: function definition file not found

…and also something like curl (6) Couldn't resolve host 'rubygems.org' (I’ve lost that actual error message).

A search on stackoverflow suggested the thing to do was to remove  ~/.zshcompdump

As far as I can understand from the zshell docs, this is something to do with autocompletion:

To speed up the running of compinit, it can be made to produce a dumped configuration that will be read in on future invocations; […] The dumped file is .zcompdump in the same directory as the startup files

Fine – sounds very deletable. And indeed, deleting it removes the errors, so I can happily leave those lines out of my .zprofile. Also, as expected, a fresh .zcompdump got generated.

One final thing: I noticed that opening a new terminal was taking slightly longer than before. Compiling the new .zcompdump seems to shave off a couple of milliseconds and makes it feel nice and responsive again:

% zcompile .zcompdump