Get interpreter path

[Michal_S]

On 15 September 2011 10:31, 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?

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

[Michal_S]

On Thu, Sep 15, 2011 at 11:50 AM, Wayne B.
[email protected] wrote:

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

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

Your issue is likely a late consequence of reading the file with
improper encoding. I can provoke the same behavior:

irb(main):001:0> s=“a”
=> “a”
irb(main):003:0> s.bytes.to_a
=> [97, 195, 159]
irb(main):004:0> File.open(“x”,“w:UTF-8”){|io|io.write s}
=> 3
irb(main):005:0> t = File.open(“x”,“r:UTF-8”){|io|io.read}
=> “a”

Now we are reading with the wrong encoding:

irb(main):008:0> t = File.open(“x”,“r:ASCII”){|io|io.read}
=> “a\xC3\x9F”
irb(main):009:0> t.bytes.to_a
=> [97, 195, 159]
irb(main):010:0> t.gsub(/./){“X”}
ArgumentError: invalid byte sequence in US-ASCII
from (irb):10:in gsub' from (irb):10 from /opt/bin/irb19:12:in ’
irb(main):011:0>

The error does not show up during loading but during gsub. If you
define the target encoding, the error pops up earlier:

irb(main):012:0> t = File.open(“x”,“r:ASCII:UTF-8”){|io|io.read}
Encoding::InvalidByteSequenceError: “\xC3” on US-ASCII
from (irb):12:in read' from (irb):12:in block in irb_binding’
from (irb):12:in open' from (irb):12 from /opt/bin/irb19:12:in ’

Kind regards

robert

[Michal_S]

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

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

[Michal_S]

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

[Michal_S]

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

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.

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.

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.

started on the joke of LSB).

Let Distributions rot.

And by the way, Michal S. 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.

[Michal_S]

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

So long as I always use gems, sure.

Which is a given on Ruby 1.9, since RubyGems is part of the standard
lib since 1.9’s release. If it isn’t available, it’s because the
distributor broke Ruby (more or less).

And on 1.8.x, you can pretty much assume RubyGems as a given, as well,
since its the canonical way to acquire programs and libraries.

Pure users (as in: “Not Ruby developers”) might not have it, but you
can provide the RubyGems source and have it be installed in such a
case.

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

It’s definitely their problem! Consider a Ruby that is compiled by
hand, and doesn’t support all language/OS features: The possible
iterations of potential Ruby variations is staggering.

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

Even then it is true: You aren’t responsible for features that Apple
(or MS, or Debian, or…) decides to include and make available to
their users. If those implementations are buggy, you can provide
workarounds (“install Ruby again”), but certainly don’t have to bend
over backwards to make something work.

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

Keep in mind that Windows and Mac OS X are very different OSes! This
assumption does not necessarily hold true. Apple includes Ruby (And an
outdated one at that, as Apple is wont to do), since they use it
themselves.

–
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