On May 18, 11:36 am, Jeff S. email@example.com wrote:
I just intstalled Ruby 1.9 on my mac with macports. The installation
was successful but when I type in ruby -v at the command prompt, Ruby
1.8.6 shows up still. The latest Pickaxe book says I have to have /opt/
local/bin in my path to add it… but don’t really get how that’s
supposed to work.
when I type in: echo ‘export PATH="/opt/local/bin:$PATH"’ >>
You’re not supposed to see anything happen, except that the shell should
prompt you for the next command.
I’m assuming you’re using “bash” (Bourne Again SHell), the default
command-line shell on Mac OS X (and most Linux distros). Since “hash
-r” is not working, you may not be using bash, after all. The next most
likely candidate is called tcsh. What do you see when you run this?
It’s also traditional for different shells to use different prompts.
Bash uses $, csh uses %, and tcsh uses % or >. As a special case, the
root user’s prompt is always set to the comment character (#), to avoid
accidental copy/paste mishaps.
When bash sees
echo 'export PATH="/opt/local/bin:$PATH" >> ~/.profile
it does a several things. One is to expand the tilde (~) to the path of
your home directory. Another is to recognize “echo” as a built-in
command, and execute it. The command’s standard output is redirected
(>>) to the end of the .profile, and echo’s command line arguments are
Be careful not to mix up >> with a single >, which would redirect echo’s
standard output to overwrite the file entirely.
The bash command:
prefixes “/opt/local/bin:” to the value of the PATH environment
variable, and marks that variable as “exported” so its value will be
inherited by subprocesses. The equivalent command in tcsh is:
setenv PATH "/opt/local/bin:$PATH"
The PATH variable holds a colon-separated list of directories to check
for the programs you invoke. For example, when you type ruby, the shell
should find /opt/local/bin/ruby. By contrast, if you were to type
xeyes, the shell would check for /opt/local/bin/xeyes, but then have to
keep looking through PATH (since xeyes lives in /usr/X11/bin).
The point of setting PATH in ~/.profile is that bash reads .profile when
you “log in.” Logging in, in this context, just means starting a new
terminal. You also want to set it for the current shell, so you end up
enter the export command twice: Once as an argument to echo
~/.profile, and again at the current shell’s prompt.
When bash finds the location of a program, it may cache that location,
to make future look-ups faster. If you change PATH, it’s a good idea to
make bash throw away its cache, and look up program locations anew. The
command to make bash discard its cache is
The equivalent for tcsh is
if I type in: echo ‘export PATH="/opt/local/bin:$PATH"’
i get: export PATH="/opt/local/bin:$PATH" on the terminal screen
To the shell, double quotes (") mean “group these things into a single
command-line argument, but expand any environment variables.” Single
quotes (’) perform the grouping, but also prevent expansion. You need
single quotes for the echo to .profile, because you want $PATH to be
expanded when the shell
For example, given the following commands:
hello='What is up'
echo $hello world
echo "$hello world"
echo '$hello world'
echo will be invoked three times, each with a different set of
arguments. In the first case, the two arguments will be ‘What is up’
and ‘world’ (without the quotes). The double space will be lost, and
echo will just print a single space between its arguments. In the
second case, echo will receive the single argument ‘What is up world’
(without quotes), with the variable expanded and the double space
preserved. In the third case, echo will receive the literal text
‘$hello world’ (again, no quotes), exactly as it was entered on the
and when i type in: hash -r
the terminal says -r isn’t valid
That’s a little odd. What happens when you type rehash?