Une bévue wrote:
Paul L. [email protected] wrote:
Figure out what your search path is and symlink the desired Ruby version
into the earliest (first searched) executable directory.
i don’t understand, if the desired version is the first hit in my search
path then, no need for a symlink…
The point is to know which version you are executing. If you only want
to
execute one version of Ruby, then remove the other two from your system.
Otherwise you will have times when you are not sure which version gets
executed. A symlink can simplify this problem, and it can do so without
some of the problems you are having with environmental variables.
this is the case obviously i arranged the PATH such a way it hits first
/opt/local/bin/ruby.
What? You are editing your search path? This is another bad idea. When
you
edit your search path and launch a new shell, previously launched shells
will use the old search path and new shells will use the new search
path.
Also, different shells may treat the path differently, depending on how
(or
if) they get the new path information. This can be very, very confusing.
Conclusion? Don’t edit your search path. Change Ruby versions some other
way. Like with symlinks.
and then using the shebang “/usr/bin env ruby” i get the right one on my
computer that’s to say the ones under /opt and a user of mine using the
ones installed by Apple (being /usr/bin/ruby) with the same script and
the same shebang said : “OK works fine !”
All fine, except these problems you are having.
again normally i don’t care of the Apple default supplied Ruby BUT for
testing purpose i might have to use it in order to verify my script
under testing is able to work with the default ruby version on MacOS X
(i’ve never done X-platform ruby).
And unfortunately, on my box, due to env vars the Apple’s one isn’t
working with the shell i’m using (zsh).
Don’t use environmental variables to try to force use of a particular
version of Ruby. Some applications will not read the variables the way
you
expect. And the problem with existing shells, new shells and your path
applies to environmental variables as well.
then using the default Apple’s ruby, i get an error message :
/usr/bin/ruby: No such file to load – ubygems (LoadError)
for a script which don’t use any gem and also with no one env var set to
“ubygems” rather i do have effectively :
export RUBYOPT=rubygems
then the first “r” is mangled at leat…
Another reason not to rely on environmental variables.
in the mean time i’ve added an alias (*) to my shell setup :
alias aruby=‘/usr/bin/ruby’ # Apple’s ruby
Aliases? Why, oh why, are you making this so complicated?
If you use an alias, or if your change your path, or if you rely on
environmental variables, each of these will lead to confusion and
errors,
because different shells treat these quantities differently, and new
shells
will have different values than old shells.
Also, if you use the “system()” call or use backticks in your Ruby
program,
which shell will you be using? Do you know? Which environmental values,
which aliases, which path will be in force for that shell?
For all these reasons, IMHO you should stop using these methods.
/usr/bin/ruby: No such dile to load – ubygems (LoadError)
which i don’t understand where it comes from…
You may not know, but I think I know. Your entire setup is way too
complicated.
- I think it’s better to use aliases rather than symlink because with
that way i leave everything installed by Apple untouched.
Except:
-
You can’t make a particular version of Ruby run.
-
Perfectly good Ruby code raises bogus error messages.
I would think this would make you wonder whether your setup is working
as it
should.
Then test whether this worked. As a normal user:
$ ruby -version
But having multiple Ruby versions installed is a bad idea, because the
different versions use libraries, some of them shared, that may cause
conflicts.
Quiet frankly i don’t think it is a bad idea having different version
because the first one is the default installed ny Apple MacOS X and
seems to be used by MacOS X then this one i want to leave it untouched.
All fine, except that you cannot make your present setup work.
alias jruby=“$JRUBY_HOME/jruby”
alias jgem=“$JRUBY_HOME/jruby $JRUBY_BIN/gem --config-file
$HOME/.jgemrc”
etc…
Yes, “no prob at all” except all the problems you just listed. If the
situation had “no prob at all” you would not have posted, and your
error-free code would execute without error messages.