Get interpreter path

ruby-talk
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

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

···

Am 14.09.2011 15:35, schrieb Michal Suchanek:

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

···

--
Posted via http://www.ruby-forum.com/\.

4

Why?

···

On Wed, Sep 14, 2011 at 3:35 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

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

--
Phillip Gawlowski

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

5

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

--
Posted via http://www.ruby-forum.com/\.

6

Some instructions for installing from DEB and RPM packages, or
batch/shell scripts that automate it somewhat, would be nice too.
While it should generally be assumed that users of Linux distributions
that use DEB and RPM packages by default know how to use the
provided tools to install from the standard archives, installing
software from outside those archives is a different story, and
is sometimes quite nonobvious to end users.

Do you really want to invest your time to teach people how to
use distribution specific solutions? Debian has been known to
aggressively cripple packages like ruby into oblivion.

There is only one true way to use ruby, which is to man up and
compile it from source.

Everyone else should be left alone to the distribution and stick
to the mess these Distributions made for them. Distributions claim
to make the life easier, so they should either stick to the
distribution or compile from source.

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

No. Package management the way it is done is a huge problem.

Distributions purposely become incompatible with one another.

Once a user leaves that path, he is on his own.

Distributions are evil.

To recommend them to stick to their distribution is playing the
devil's advocate.

For users who have changed the default behavior of the system, I
agree, but for those who are using the system as it is delivered
to end users I sympathize with the desire to make things as
seamless as possible. This can be important if for no other
purpose than reaching as many users as one reasonably can.

Again, if idiots that create a Distribution make the life of users
AND developers harder, it is time to tell the users to start
using their brains rather than subjugate to the tyranny of stupid
decisions made within a distribution.

They purposely cripple packages for everyone, for no real valid
reason whatsoever.

They purposely remain incompatible with one another (don't get me
started on the joke of LSB).

Let Distributions rot.

And by the way, Michal Suchanek asked a simple question. It would
be polite to not ask "why he is doing it", but to either answer
the question, or not - and not try dilute the problem to another
domain like Mr. Gawlowski tried.

···

--
Posted via http://www.ruby-forum.com/\.

7

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

Regards,
Florian

···

On Sep 14, 2011, at 7:43 PM, Roger Pack 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

8

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

···

On 14 September 2011 20:47, Phillip Gawlowski <cmdjackryan@gmail.com> wrote:

On Wed, Sep 14, 2011 at 3:35 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

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

Why?

9

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!

···

On Thu, Sep 15, 2011 at 10:31 AM, Alex Young <alex@blackkettle.org> 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?

--
Phillip Gawlowski

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

10

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?

That's not what I am doing, at least right now. That's one of the
things that comes up often when searching for the ruby interpreter
path.

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.

That definitely won't do.

I can run ruby1.8 mytest.rb or ruby1.9.2 mytest.rb and exec "#{$0}"
would just fail because I did not bother to make the file executable.

Thanks

Michal

···

On 15 September 2011 10:31, Alex Young <alex@blackkettle.org> wrote:

11

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

···

On 14 September 2011 19:39, Quintus <sutniuq@gmx.net> wrote:

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

Am 14.09.2011 15:35, schrieb Michal Suchanek:

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"])

12

>
> Some instructions for installing from DEB and RPM packages, or
> batch/shell scripts that automate it somewhat, would be nice too.
> While it should generally be assumed that users of Linux distributions
> that use DEB and RPM packages by default know how to use the
> provided tools to install from the standard archives, installing
> software from outside those archives is a different story, and
> is sometimes quite nonobvious to end users.

I said that.

Do you really want to invest your time to teach people how to
use distribution specific solutions? Debian has been known to
aggressively cripple packages like ruby into oblivion.

There is only one true way to use ruby, which is to man up and
compile it from source.

Everyone else should be left alone to the distribution and stick
to the mess these Distributions made for them. Distributions claim
to make the life easier, so they should either stick to the
distribution or compile from source.

translation: "Ruby has too many users. We don't need people who want to
make things relatively easy."

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

I didn't say that.

No. Package management the way it is done is a huge problem.

Distributions purposely become incompatible with one another.

Once a user leaves that path, he is on his own.

Distributions are evil.

To recommend them to stick to their distribution is playing the
devil's advocate.

How do you do things? Do you start by compiling a Linux kernel from
sources at Kernel.org? Do you use FreeBSD? I'm curious.

>
> For users who have changed the default behavior of the system, I
> agree, but for those who are using the system as it is delivered
> to end users I sympathize with the desire to make things as
> seamless as possible. This can be important if for no other
> purpose than reaching as many users as one reasonably can.

I said that.

Again, if idiots that create a Distribution make the life of users
AND developers harder, it is time to tell the users to start
using their brains rather than subjugate to the tyranny of stupid
decisions made within a distribution.

They purposely cripple packages for everyone, for no real valid
reason whatsoever.

They purposely remain incompatible with one another (don't get me
started on the joke of LSB).

Let Distributions rot.

And by the way, Michal Suchanek asked a simple question. It would
be polite to not ask "why he is doing it", but to either answer
the question, or not - and not try dilute the problem to another
domain like Mr. Gawlowski tried.

I'm not entirely sure what all that has to do with what I said.

By the way, it might be nice if there were some quote attribution in your
replies so that readers would know who said what. It's the polite thing
to do.

···

On Fri, Sep 16, 2011 at 12:25:03AM +0900, Marc Heiler wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

13

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

···

On 14 September 2011 20:08, Florian Gilcher <flo@andersground.net> wrote:

On Sep 14, 2011, at 7:43 PM, Roger Pack 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.

14

Why would you *care* where it is installed?

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

···

On Wed, Sep 14, 2011 at 8:56 PM, Michal Suchanek <hramrach@centrum.cz> wrote:

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

Is that too hard to understand?

--
Phillip Gawlowski

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

15

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

···

On Wed, Sep 14, 2011 at 2:56 PM, Michal Suchanek <hramrach@centrum.cz>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

16

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 Gilcher

smtp: flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg: 533148E2

17

- .deb packages for Debian and derivatives
- .rpm packages for Fedora, OpenSUSE, and derivatives (RHEL,
SLED/SLES, and CentOS/SL as RHEL derivatives)

I'll refer back to this stuff in a moment.

- Include the source for Ruby (GPL mandates access to the sources
anyway, if binaries are distribute, so might as well fill up the CD)

This is evidently not the case with 1.9.3 (and future versions,
presumably). It appears that the dual-licensing status of Ruby is
changing [1] from (Ruby License or GPL) to (Ruby License or Simplified
BSD License), thankfully.

I still believe that including the source is a good idea, as is a README
that explains everything on the storage media.

- Instructions to build from source, if no binary package is distributed

Some instructions for installing from DEB and RPM packages, or
batch/shell scripts that automate it somewhat, would be nice too. While
it should generally be assumed that users of Linux distributions that use
DEB and RPM packages by default know how to use the provided tools to
install from the standard archives, installing software from outside
those archives is a different story, and is sometimes quite nonobvious to
end users.

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

For users who have changed the default behavior of the system, I agree,
but for those who are using the system as it is delivered to end users I
sympathize with the desire to make things as seamless as possible. This
can be important if for no other purpose than reaching as many users as
one reasonably can.

## Notes:

1. https://github.com/ruby/ruby/blob/trunk/COPYING

···

On Thu, Sep 15, 2011 at 05:43:01PM +0900, Phillip Gawlowski wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

18

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.)

19

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.

···

On Sep 14, 2011, at 11:43 AM, Michal Suchanek 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"

20

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

···

On 14 September 2011 21:06, Phillip Gawlowski <cmdjackryan@gmail.com> wrote:

On Wed, Sep 14, 2011 at 8:56 PM, Michal Suchanek <hramrach@centrum.cz> 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?