Question based on an assertion made in another thread…
I was under the impression that $LOAD_PATH is relative to the current
location of the ruby executable. On Windows this certainly seems to be
the case. I can move ruby.exe and see that $LOAD_PATH changes.
However, on Linux this doesn’t seem to be the case, no matter where I put
the ruby binary, $LOAD_PATH points to /usr/local/lib/ruby/…
Is there anyway to make $LOAD_PATH relative on Linux (and I suspect also
on Windows if you use MingW to compile) just as it is on the Windows
mswin32 build?
…I’m hoping this is just a configure command-line switch since I need to
put the Ruby binary and some libs on a CDROM and have it execute from
there.
Question based on an assertion made in another thread…
I was under the impression that $LOAD_PATH is relative to the current
location of the ruby executable. On Windows this certainly seems to be
the case. I can move ruby.exe and see that $LOAD_PATH changes.
However, on Linux this doesn’t seem to be the case, no matter where I put
the ruby binary, $LOAD_PATH points to /usr/local/lib/ruby/…
Is there anyway to make $LOAD_PATH relative on Linux (and I suspect also
on Windows if you use MingW to compile) just as it is on the Windows
mswin32 build?
…I’m hoping this is just a configure command-line switch since I need to
put the Ruby binary and some libs on a CDROM and have it execute from
there.
You can add to $LOAD_PATH when the script starts, and those paths can be
relative to the script itself. Does that help? For example,
HERE = File.dirname(__FILE__) # __FILE__ does not alwyas == $0
$LOAD_PATH << HERE # Add script's directory
$LOAD_PATH << File.join(HERE, '..') # Add directory above script
Since you are in control of the directory structure on the CD, you should be
able to find the Ruby libs relative to the script.
You could also use the -I command line switch or the environment variable
RUBYLIB to add to the list of directories to search.
Question based on an assertion made in another thread…
I was under the impression that $LOAD_PATH is relative to the current
location of the ruby executable. On Windows this certainly seems to be
the case. I can move ruby.exe and see that $LOAD_PATH changes.
However, on Linux this doesn’t seem to be the case, no matter where I put
the ruby binary, $LOAD_PATH points to /usr/local/lib/ruby/…
Is there anyway to make $LOAD_PATH relative on Linux (and I suspect also
on Windows if you use MingW to compile) just as it is on the Windows
mswin32 build?
…I’m hoping this is just a configure command-line switch since I need to
put the Ruby binary and some libs on a CDROM and have it execute from
there.
Phil
In a shell window, set the environment variable RUBYLIB with the list
of paths you want to use.
Question based on an assertion made in another thread…
I was under the impression that $LOAD_PATH is relative to the current
location of the ruby executable. On Windows this certainly seems to be
the case. I can move ruby.exe and see that $LOAD_PATH changes.
However, on Linux this doesn’t seem to be the case, no matter where I put
the ruby binary, $LOAD_PATH points to /usr/local/lib/ruby/…
Is there anyway to make $LOAD_PATH relative on Linux (and I suspect also
on Windows if you use MingW to compile) just as it is on the Windows
mswin32 build?
…I’m hoping this is just a configure command-line switch since I need to
put the Ruby binary and some libs on a CDROM and have it execute from
there.
You can add to $LOAD_PATH when the script starts, and those paths can be
relative to the script itself. Does that help? For example,
HERE = File.dirname(FILE) # FILE does not alwyas == $0
$LOAD_PATH << HERE # Add script’s directory
$LOAD_PATH << File.join(HERE, ‘…’) # Add directory above script
Since you are in control of the directory structure on the CD, you should be
able to find the Ruby libs relative to the script.
You could also use the -I command line switch or the environment variable
RUBYLIB to add to the list of directories to search.
True, I could do those things, but I’m wondering how they managed to make
$LOAD_PATH relative on Windows?
Because Ruby was coded to work that way. Why it wasn’t made to do it
under *nix, I have no idea. I think it’s a critical requirement,
otherwise having private copies of Ruby installs is impossible. It will
always go to /usr/lib/ruby, etc. no matter where Ruby is run from.
After my message about this subject was ignored (Installation/Config
question), I decided to just write it myself and patch Ruby.
Here’s what I did.
After ./configure - the bottom of config.h must be changed to be rooted
off of /lib (the rest stays the same) #define LOAD_RELATIVE 1 must also be added.
in ruby.c in the ruby_init_loadpath() method I added a #else section
after the #elif defined(_EMX) which was withih the #if defined
LOAD_RELATIVE section.
It looked something like this: #elif defined(EMX)
_execname(libpath, FILENAME_MAX); #else
/* pmb 03/01/2004 */
buf = malloc(size);
while ((rv = readlink(“/proc/self/exe”, buf, size)) == size) {
size *= 2;
buf = realloc(buf, size);
}
if (rv < 0 || rv >= FILENAME_MAX) {
free(buf);
fprintf(stderr, “Unable to get path to self through
/proc/self/exe”);
exit(1);
}
strncpy(libpath, buf, rv);
libpath[rv] = ‘\0’;
free(buf); #endif
True, I could do those things, but I’m wondering how they managed to make
$LOAD_PATH relative on Windows?
Because Ruby was coded to work that way. Why it wasn’t made to do it
under *nix, I have no idea. I think it’s a critical requirement,
otherwise having private copies of Ruby installs is impossible. It will
always go to /usr/lib/ruby, etc. no matter where Ruby is run from.
After my message about this subject was ignored (Installation/Config
question), I decided to just write it myself and patch Ruby.
I’ve always been able to install private Rubies. I just set --prefix
when ./configure’ing. Does that not do what you need?
I’ve always been able to install private Rubies. I just set --prefix
when ./configure’ing. Does that not do what you need?
No, I needed to define a Ruby tree that could be installed (through
source control checkout) anywhere by a user. ‘Fixed’ paths are IMO,
unacceptable. It works quite well in Windows. I was really surprised
to find that it was all hard-coded for *nix installs.
No, I needed to define a Ruby tree that could be installed (through
source control checkout) *anywhere* by a user. 'Fixed' paths are IMO,
unacceptable. It works quite well in Windows. I was really surprised
to find that it was all hard-coded for *nix installs.
No, I needed to define a Ruby tree that could be installed (through
source control checkout) anywhere by a user. ‘Fixed’ paths are IMO,
unacceptable. It works quite well in Windows. I was really surprised
to find that it was all hard-coded for *nix installs.
security problem
…and it wouldn’t be under Windows? Sorry, I don’t buy it.
Quoteing patrick.bennett@inin.com, on Sun, Mar 21, 2004 at 02:18:01AM +0900:
>> No, I needed to define a Ruby tree that could be installed (through
>> source control checkout) *anywhere* by a user. 'Fixed' paths are IMO,
>> unacceptable. It works quite well in Windows. I was really surprised
>> to find that it was all hard-coded for *nix installs.
>
>security problem
How (it's impossible) to find a process's executable file in Unix is a
FAQ:
Executables in unix don't have a knowledge of "where they are". They
don't, in fact, have to "be" anywhere. Some are even built into the boot
image, so don't in fact have to have ever "been" anywhere.
Do I recall you saying that you'd hacked ruby to get it's executable
location? I'd like to see that hack, I'm pretty confident I can think up
a number of cases where it wouldn't work.
Also, why would you think that something that is a security concern in
unix would be in windows? Windows isn't even a multi-user OS! It also
doesn't support hard or symbolic links, or set-user-id flags on
executables, or allow you to delete a running executable, you can in
unix.
Executables in unix don’t have a knowledge of “where they are”. They
don’t, in fact, have to “be” anywhere. Some are even built into the boot
image, so don’t in fact have to have ever “been” anywhere.
Well, on some operating systems it’s certainly possible to find the
executable image corresponding to a process (eg: Linux) and on others
you can find the device number / inode no. of each text section within
the process.
Of course, none of this is really important right now, since I belive he
was referring to the fact that a program could be fooled into reading a
different configuration file to the one the administrator intended, if a
user were to either copy or create a link to the binary somewhere they
had write access to. Of course, it shouldn’t be a problem on a well
configured system, but that’s something of an ideal.
Do I recall you saying that you’d hacked ruby to get it’s executable
location? I’d like to see that hack, I’m pretty confident I can think up
a number of cases where it wouldn’t work.
Operating systems that aren’t Linux being the main case here.
Windows isn’t even a multi-user OS! It also
doesn’t support hard or symbolic links, or set-user-id flags on
executables, or allow you to delete a running executable, you can in
unix.
Windows 2000 and XP support both multi-user operation and soft/hard
links with NTFS.
1-2 weeks ago I asked the same question about a Linux binary Ruby
installation that can be installed anywhere in users’ home directory
(without the user building Ruby himself). To accomplish this, the
following is needed:
build Ruby with --enable-load-relative (you must patch Ruby with ±
100-line patch from Nobu; sorry I couldn’t search ruby-talk.org at the
moment but it’s around the first week of March 2004) which will make
$LOAD_PATH relative;
either:
a) make a small wrapper for ruby executable, which makes Ruby find its
shared libraries in “…/lib” instead of only in /lib, /usr/lib, and
other paths specified in /etc/ld.so.conf; (I’m attaching the small
wrapper I wrote, which again was kindly revised by Nobu);
b) build a static version of Ruby (–disable-shared in configure
option), which will then depend only on basic shared libraries (like glibc).
After that, you can just bundle the resulting Ruby installation.
