Get interpreter path

Ruby
1

Hello,

is any way to get the running interpreter path?

I found some people asking for it but no solution.

I don’t want to know where the interpreter was installed, I want to
know where it was run from.

It would be quite helpful to re-execute the interpreter when running
tests sometimes.

Thanks

Michal

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 14.09.2011 15:35, schrieb Michal S.:

Hello,

is any way to get the running interpreter path?

I found some people asking for it but no solution.

I don’t want to know where the interpreter was installed, I want
to know where it was run from.

I’m not sure what you mean, but it seems you don’t want the RbConfig
thing, i.e.

require “rbconfig”
File.join(RbConfig::CONFIG[“bindir”],
RbConfig::CONFIG[“ruby_install_name”])

It merely sounds you want the current working directory. You can
access it via

Dir.pwd

Am I right on this?

Thanks

Michal

Vale,
Marvin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOcOa0AAoJELh1XLHFkqhaAAUIAJR10rK+Ptd1/3wQX+Mn39Er
8qCQWeQ4wfTq3s5Dbep5Scy+EIwzwzhjPGIGXtrTm5fOyRpOsdfmvaYuB3gJb7n2
W49AS2Iz0hfZ0o4IysoUXClnUVKFBPUup65Y4YHXEgpV72DX0ZumvNtcES+XY5F6
vOGBG3lMxOfDWWjeo47hKcW5x3msVCQlRW0/abR2M+gOo97N/+P7Bk3L+vVbwwgK
jwoDVNB4NF5YzEqUI2YEuyXlPyIrQZEb5TvBP4wWEf4ySOsfnonTf6Mrz6K2TTRE
7fMSKPSwmjCHF5CAQ0f1rSukZ4j2ebd+qCR0YiQcYZOoeFhBi33yu6blF4ye5xk=
=n3PT
-----END PGP SIGNATURE-----

3

get current interpreter path

Gem.ruby # if you have rubygems loaded
or

OS.ruby_bin
=> “C:/installs/Ruby187/bin/ruby.exe”

with the OS gem.
-r

4

On Sep 14, 2011, at 7:43 PM, Roger P. wrote:

get current interpreter path

Gem.ruby # if you have rubygems loaded
or

OS.ruby_bin
=> “C:/installs/Ruby187/bin/ruby.exe”

with the OS gem.
-r

To add to that: rake adds the constant RUBY, which also holds the path
of the interpreter running the Rakefile.

Regards,
Florian

5

On Wed, Sep 14, 2011 at 3:35 PM, Michal S. [email protected]
wrote:

I don’t want to know where the interpreter was installed, I want to
know where it was run from.

Why?

–
Phillip G.

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

6

On 14 September 2011 20:47, Phillip G. [email protected]
wrote:

On Wed, Sep 14, 2011 at 3:35 PM, Michal S. [email protected] wrote:

I don’t want to know where the interpreter was installed, I want to
know where it was run from.

Why?

Obviously because I can’t be sure that the interpreter is in the
place it was installed.

Is that too hard to understand?

Thanks

Michal

7

On Wed, Sep 14, 2011 at 8:56 PM, Michal S. [email protected]
wrote:

Obviously because I can’t be sure that the interpreter is in the
place it was installed.

Is that too hard to understand?

Why would you care where it is installed?

IOW: What’s the problem you are actually trying to solve?

–
Phillip G.

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

8

On 14 September 2011 20:08, Florian G. [email protected]
wrote:

with the OS gem.
-r

To add to that: rake adds the constant RUBY, which also holds the path of the
interpreter running the Rakefile.

And neither works:

cp which ruby ~/bin/testruby
testruby -rubygems -e “require ‘rake’ ; p RUBY”
“/usr/bin/ruby1.8”
testruby -rubygems -e “require ‘os’ ; p OS.ruby_bin”
“/usr/bin/ruby1.8”

Thanks

Michal

9

The original question is quite interesting. Offhand I don’t see a way
to do it. Even using something like sys-proctable wouldn’t guarantee
an accurate result. On certain Unix-style OS flavors, one might be
able to launch an external command and parse the results (i.e. using
lsof) to learn more.

Good question! If you or someone else comes up with a good idea, I
look forward to seeing it here.

Aaron out.

(OT comment: It’s easy to get frustrated on both sides of discussions,
as asker when many people wanting to be helpful ask “why” or “for what
purpose” when sometimes the asker may not want to share why or
purpose–or the purpose may simply be “because it’s a fascinating
question that has piqued my curiosity”–and as a helpful answerer,
when one doesn’t know exactly what the asker wants, trying to get more
useful information can easily lead to frustration. So for me in
either role, if I find myself getting snippy, it’s time for me to back
away, take a break or a deep breath, and just be grateful that there
are other geeks like me out there who share similar interests.)

10

On Sep 14, 2011, at 11:43 AM, Michal S. wrote:

And neither works:

cp which ruby ~/bin/testruby
testruby -rubygems -e “require ‘rake’ ; p RUBY”
“/usr/bin/ruby1.8”
testruby -rubygems -e “require ‘os’ ; p OS.ruby_bin”
“/usr/bin/ruby1.8”

Moving ruby from where it was installed is not a good idea. It expects
to be run from where make install put it, not from any other location.

11

On Wed, Sep 14, 2011 at 5:05 PM, Eric H. [email protected]
wrote:

Moving ruby from where it was installed is not a good idea. It expects to
be run from where make install put it, not from any other location.

Of course, this doesn’t mean that people won’t do that, although I’m
having
trouble thinking of a case where it would matter. FWIW, the rake example
gives me the same string if I mv $(which ruby) instead of cp’ing it, so
I
assume most of the “give me the ruby binary path” things are just going
to
be reading build info.

12

On Wed, Sep 14, 2011 at 2:56 PM, Michal S.
[email protected]wrote:

Obviously because I can’t be sure that the interpreter is in the
place it was installed.

Is that too hard to understand?

Thanks

Michal

http://catb.org/~esr/faqs/smart-questions.html

13

On Thu, Sep 15, 2011 at 12:09 AM, Michal S. [email protected]
wrote:

I don’t care where it is installed, I care where it is.

Those are synonyms, since the user can execute Ruby programs. How
the user does that is simply none of your concern, but the user’s
problem (i.e. whether it’s a copied instance of Ruby, or a full system
installation, or an RVM managed Ruby, or a script executed against all
the Rubies pik knows about are all valid and common ways to run Ruby
scripts).

check that the function works as I want.

It would be much easier if I could just run Ruby and pass it a test
program as argument.

And

$ #{Gem.ruby} /path/to/testscript

doesn’t suffice?

Makes me wonder about what you’ve written, to be honest.

On the other hand, OS X can run Ruby, has exec() and has linker
support for moving whole applications with libraries and all. I am not
sure how much Ruby would break by installing in this fashion, though.

That’s Apple’s problem, not yours.

–
Phillip G.

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

14

Reading between the lines, it sounds like Michal has an application,
including the Ruby interpreter, distributed on CD, and the users of this
application (who might not want or be able to rely on the system ruby)
want to copy it off onto their hard drives and run it from there.

Is that right?

Going back to the first email:

It would be quite helpful to re-execute the interpreter when running
tests sometimes.

On the rare occasions where this has made sense in the past, I’ve lashed
something together with exec "#{$0} ..." and detected either arguments
or environment variables.

However, I suspect that there is an easier way to get the same results
in this case

–
Alex

15

On 14 September 2011 21:06, Phillip G. [email protected]
wrote:

I don’t care where it is installed, I care where it is.

The reason is quite simple and i said it in the first mail. I was
trying to write a test for a function that redirects STDERR.

Now I have a library of functions already tested that redirects
everything but it runs a command with STD I/O/E redirected, not ruby.

AFAICT it is not possible to pass a “-” into exec to have ruby
re-executed, and exec is what I use.

So to write the test I have to use fork and do manual redirections to
check that the function works as I want.

It would be much easier if I could just run Ruby and pass it a test
program as argument.

Now I am running this on Linux so there is not much point in moving
the Ruby interpreter. There are often symlinks but the path under
which Ruby was originally installed would usually work, and I don’t
run the test during Ruby installation.

Also exec is not portable to Windows so I need not worry about that.

On the other hand, OS X can run Ruby, has exec() and has linker
support for moving whole applications with libraries and all. I am not
sure how much Ruby would break by installing in this fashion, though.

So maybe I was looking for solution needlessly general because I did
not consider the consequences of config not being enough. I guess
there are other things that would break if it weren’t.

There were people trying to install their Ruby application from a CD
and for those config would not be enough but $0 and knowledge of their
CD layout should suffice.

Thanks

Michal

16

On Thu, Sep 15, 2011 at 10:31 AM, Alex Y. [email protected]
wrote:

Reading between the lines, it sounds like Michal has an application,
including the Ruby interpreter, distributed on CD, and the users of this
application (who might not want or be able to rely on the system ruby)
want to copy it off onto their hard drives and run it from there.

Is that right?

In that case, I’d distribute Ruby as an installer package for the
distributions I want to support:

  • The Windows RubyInstaller
  • .deb packages for Debian and derivatives
  • .rpm packages for Fedora, OpenSUSE, and derivatives (RHEL,
    SLED/SLES, and CentOS/SL as RHEL derivatives)
  • Include the source for Ruby (GPL mandates access to the sources
    anyway, if binaries are distribute, so might as well fill up the CD)
  • Instructions to build from source, if no binary package is distributed

Let the users worry about how their systems are managed. That’s why
package management/installers exist, after all!

–
Phillip G.

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

17

On 15 September 2011 01:12, Phillip G. [email protected]
wrote:

check that the function works as I want.
Makes me wonder about what you’ve written, to be honest.
So long as I always use gems, sure.

It’s probably the user’s problem if they delete the Ruby interpreter
in the location where it was initially installed.

While it’s totally possible to move the interpreter and still run it
many other things would likely break.

On the other hand, OS X can run Ruby, has exec() and has linker
support for moving whole applications with libraries and all. I am not
sure how much Ruby would break by installing in this fashion, though.

That’s Apple’s problem, not yours.

That’s true so long as I don’t try to run anything on such Ruby
installation.

Also Apple sidestepped this by including Ruby in the system core where
it is always installed in /usr.

But since Ruby works on Windows it should work as a standalone
application on OS X too.

Thanks

Michal

18

Hi,

Without discussing the benefits or drawbacks: Finding the real
executable of the current program is highly dependent of the OS in use.

So, without further ado, here are two links that give you pointers you
how to “roll your own” solution:

Regards,
Florian

P.S.: By the way, uninstalled Ruby is unsupported by ruby core, so any
library expects this as well.

–
Florian G.

smtp: [email protected]
jabber: [email protected]
gpg: 533148E2

19

On 14 September 2011 19:39, Quintus [email protected] wrote:

I don’t want to know where the interpreter was installed, I want
to know where it was run from.

I’m not sure what you mean, but it seems you don’t want the RbConfig
thing, i.e.

require “rbconfig”
File.join(RbConfig::CONFIG[“bindir”],
RbConfig::CONFIG[“ruby_install_name”])

This is probably going to suffice.

I would have to ask on what ruby is the test running if it does not.

Thanks everybody for all the replies

Michal

20

First off, I’m very new to Ruby and I’m trying to wrap my head around a
few things, so if this sounds simplistic I apologize in advance I did do
some searching but I’m not sure how to fix this error.

I’m using Mac OS X (Lion) and I’ve started a script that reads in an xml
file (ditamap) and parses the data, so I only end up with a listing of
files that map uses.

When I run the script using Ruby 1.8.x, the script works as I expected
it to work. However, when I run it using Ruby 1.9.x, I get the
following error:

`gsub’: invalid byte sequence in US-ASCII (ArgumentError)

From what I’ve determined via the web, this has to do with some
mis-match of what the OS is using vs. what Ruby is using. One post I
read recommended reading the file as a binary to get around this.
However, I’m wondering what the real fix is for this problem, and why is
it happening in 1.9 vs. 1.8.

For the record, here is how I’m opening my files:

ditamap_file= File.read(“v5630097.ditamap”)

Thanks,
Wayne