What we'll cover
- Understanding the Unix Environment
Want to skip all the hard work?
Check out my automated environment setup doctor.
We'll start by testing that
subl is somewhere in our
$PATH (we'll cover
$ which subl /usr/local/bin/subl
If this comes back blank, then we need to set up the
subl command. A quick
Google search for "Sublime command line" gives me the
These directions will link the
subl executable packaged with the Sublime
Application to your
$HOME/bin directory. Before you can link the command,
you'll want to ensure you have a
$HOME/bin directory (
mkdir -p $HOME/bin)
$HOME/bin is in your
I recommend putting the symlink in
/usr/local/bin instead of
Here's how I do it:
$ find /Applications/Sublime\ Text\ 2.app -name subl /Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl $ ln -fs "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" /usr/local/bin/subl $ which subl /usr/local/bin/subl
The Unix Environment
The Unix environment is a huge topic. For today's purposes, we'll be interacting with a few pieces:
$ echo $PATHor a bit more useful
$ echo $PATH | tr : '\n'
$ which <some_command>and
$ which -a <some_command>
/etc/paths(and why you shouldn't modify this)
- Your prompt.
- Your login environment's customizations
First let's ensure we've installed homebrew correctly.
$ which brew /usr/local/bin/brew
If you don't see this, run:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Homebrew is going to do a lot of work for us, so always ensure that it's up-to-date and that it's healthy.
$ brew doctor # … LOTS OF STUFF THAT NEEDS TO BE FIXED …
brew doctor may tell you a lot of stuff… you'll want to read through each
item, and attempt to resolve the issue for Homebrew. We're ideally shooting for
a message like this:
$ brew doctor Your system is ready to brew.
Adjusting $PATH for Homebrew
Homebrew is going to be installing packages and tools for us, so we need to make sure that when possible our system is using homebrew's installed packages.
We'll start by inspecting our path
$ echo $PATH | tr : '\n' /Users/mike/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/bin
/usr/local/bin comes before
If it doesn't, open
$HOME/.bash_profile using Sublime Text and add the
Also check out the rbenv documentation.
sqlite3 using Homebrew
$ brew install sqlite3
OS X provides
sqlite3 for you, so we'll need to force homebrew to link it so
that we can use the homebrew version by default:
$ brew link sqlite3 --force
postgres using Homebrew
$ brew install postgres
postgres is a piece of software that requires a server to interface with. It's
easiest to let OS X's
launchd utility keep this server running, otherwise we'd
have to restart it every time it died or our machine rebooted.
$ ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents $ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
$ which postgres /usr/local/bin/postgres
$ which psql /usr/local/bin/psql
Now Homebrew will keep our postgres server alive so that we can just develop
awesome apps and not worry about the database. Let's ensure that we have a
server running. To do that we'll use
ps aux | grep postgres mike 444 0.0 0.0 2439324 148 ?? Ss 13Feb14 0:02.33 postgres: stats collector process mike 443 0.0 0.0 2443176 624 ?? Ss 13Feb14 0:02.44 postgres: autovacuum launcher process mike 442 0.0 0.0 2443044 80 ?? Ss 13Feb14 0:03.72 postgres: wal writer process mike 441 0.0 0.0 2443044 132 ?? Ss 13Feb14 1:29.90 postgres: writer process mike 440 0.0 0.0 2443044 136 ?? Ss 13Feb14 0:00.14 postgres: checkpointer process mike 403 0.0 0.0 2443044 68 ?? S 13Feb14 0:00.40 /usr/local/opt/postgresql/bin/postgres -D /usr/local/var/postgres -r /usr/local/var/postgres/server.log mike 6469 0.0 0.0 2432768 600 s000 R+ 5:42PM 0:00.00 grep postgres
The process with
pid (process id) #403 is our server process. You can see here
what executable (the full path) is running, where the data file is (ie.
/usr/local/var/postgres), and where we can find the logs (ie.
Finally, create a default database and test our postgres client,
createdb $USER psql $USER # this is a sql console for interacting with a postgres database
Managing Ruby Installations
chruby? There are a number of different popular tools for
installing/managing/using different versions of ruby on your machine.
We're going to use
rbenv (that's what's on the DBc workstations). If you
rvm installed, you are fine, and can skip this portion.
Verifying your Ruby Manager
which rbenv $HOME/.rbenv/bin/rbenv OR /usr/local/bin/rbenv
which rvm $HOME/.rvm/bin/rvm
rbenv using Homebrew
$ brew install ruby-build rbenv
rbenv will store rubies and gems to
$HOME/.rbenv. There's no need to change
ruby-build is the tool that will do the installing.
rbenv is installed, we need to configure our environment to use it.
The instructions say that we need to add the following to our
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
$ rbenv install --list # will list all of the Rubies ruby-build can install $ rbenv install 2.0.0-p353 # will install ruby 2.0.0 patch 353 $ rbenv versions # will list the Rubies you already have installed $ rbenv global 2.0.0-p353 # will set the global/shell/local ruby
Let's make sure you're NOT using the system ruby.
$ which ruby /Users/mike/.rbenv/shims/ruby
If this says
/usr/bin/ruby, then we need to get your ruby installed via a ruby
version manager. I suggest rbenv (see above).
If you're using rbenv, run this:
$ rbenv which ruby /Users/mike/.rbenv/versions/2.0.0-p481/bin/ruby
Same as above, it should not say
/usr/bin/ruby. If it does, then install a
ruby (via rbenv), then set it as your default ruby (
rbenv global <ruby version you installed>).
Most gems are fairly easy to install, but there are a few that we use at DBC that can be problematic (usually the ones with native dependencies). Let's start by verifying that the gem executable is installed via a ruby version manager.
$ which gem /Users/mike/.rbenv/shims/gem
You'll notice that
gem is in the same directory as
ruby (from above). This
is good. If they aren't in the same place that's usually a problem. If it's
/usr/bin/gem that's an issue.
If you're using rbenv, run:
$ rbenv which gem /Users/mike/.rbenv/versions/2.0.0-p481/bin/gem
Again, just like ruby, this shouldn't say
/usr/bin/gem. It should also be in
the same location as when you ran
rbenv which ruby.
Let's also update rubygems.
$ gem update --system
Alright, ON TO THE HARD GEMS! First, bundler.
gem install bundler rbenv rehash // if you're using rbenv
And the rest:
gem install sqlite3 pg nokogiri
git using Homebrew
$ brew install git
Ensure we're using
git from homebrew:
$ which git /usr/local/bin/git
Question: OS X ships with
git isn't that good enough?
Answer: It might be, but it's likely out of date, and you won't benefit from new
tools and developments.
git is a tool we'll use frequently, so installing it
and keeping it up to date is akin to a chef keeping his knives sharp. Up-to-date
tools are one of the marks of a craftsman, strive to be a craftsman.
bash using Homebrew
$ brew install bash
To use this new version of bash, we'll need to add it to
/etc/shells is owned by the
root user (verify using
ls -la /etc/shells),
so we'll need to use
sudo to write to it.
$ sudo -s "echo /usr/local/bin/bash >> /etc/shells"
Now we need to change our shell command:
$ chsh -s /usr/local/bin/bash
All set. We can launch a new teminal window and verify our setup.
$ bash --version