Calvin
5/18/2009 10:30:00 PM
On May 18, 2:13 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> Calvin wrote:
> > On May 18, 11:36 am, Jeff Schwab <j...@schwabcenter.com> wrote:
> >> Calvin 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"' >>
> > ~/.profile
> > nothing happens
>
> 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?
>
> echo $SHELL
>
> 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
> exactly two:
>
> echo
> export PATH="/opt/local/bin:$PATH"
>
> Be careful not to mix up >> with a single >, which would redirect echo's
> standard output to overwrite the file entirely.
>
> The bash command:
>
> export PATH="/opt/local/bin:$PATH"
>
> 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
>
> hash -r
>
> The equivalent for tcsh is
>
> rehash
>
> > 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
> command line.
>
> > 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?
Oh- I am using bash and i think the hash -r thing worked (i think)
when i type in: which ruby1.9 I get /opt/local/bin/ruby1.9
and when I type ruby1.9 -v I get ruby 1.9.1p129
but
if I just type in: which ruby I get /usr/bin/ruby
and if I type ruby -v I get ruby 1.8.6
Thanks so much again for helping me out Jeff