On Jan 7, 2004, at 12:31 PM, Yukihiro Matsumoto wrote:

> Can you describe "what one would expect" and "little confusing"
> situation you are worrying?
>

Sorry I was a little vague.  Here's what I did that caught me up.

Installed ruby_1_8 branch in my home directory for testing under ~/stmp;
Then tried

~/stmp/bin/ri Array#length

Of course this fails because I need to do

~/stmp/bin/ruby ~/stmp/bin/ri Array#length

to pick up the correct ruby

Not a big deal.  OTOH I used to work at a site which had thousands of 
users and maintained separate /prod, /beta, and /devel mounts for all 
software officially "released".  The idea being that some users could 
run from /beta/bin while most were still using /prod/bin.  Etc.  You 
get the idea.  To try out the new version you'd run /devel/bin/ruby.

My worry is that people will explicitly run /devel/bin/irb and not 
realize that it's not new version but the old one.  The one that's in 
their PATH.  In my case, I'd be getting ri documentation from 
/prod/lib/ruby when I thought I was explicitly asking for 
/devel/lib/ruby

Another way this could screw up is if someone were trying to automate 
tasks via scipting.  Say for example you want to generate a bunch of 
rdoc documentation from some common directories via cron.  A naive 
sysadmin might do the following

/usr/local/bin/rdoc ...

This has the potential to fail due to a mis-configured PATH.  To be 
safe you'd do

/usr/local/bin/ruby /usr/local/bin/rdoc ...

or

PATH=/usr/local/bin /usr/local/bin/rdoc ...

Even worse, the update_my_rdoc script above might fail for some users 
while it works for others.

In my own case, I could do

cd ~/stmp/bin; ./ri

and it will still fail.  I'm saved by my knowledge that ri is really a 
ruby script but naive users might find it confusing.

-J