Get interpreter path

[Jeremiah_Dodds1 (Jeremiah Dodds)]

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.

···

On Wed, Sep 14, 2011 at 5:05 PM, Eric Hodel <drbrain@segment7.net> 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.

[Phillip_Gawlowski]

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

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.

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.

···

On Thu, Sep 15, 2011 at 12:09 AM, Michal Suchanek <hramrach@centrum.cz> wrote:

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

[Michal_hramrach_Such (Michal 'hramrach' Suchanek)]

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

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.

And

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

doesn't suffice?

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

···

On 15 September 2011 01:12, Phillip Gawlowski <cmdjackryan@gmail.com> wrote:

On Thu, Sep 15, 2011 at 12:09 AM, Michal Suchanek <hramrach@centrum.cz> wrote:

[Wayne_Brissette]

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

[Phillip_Gawlowski]

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.

···

On Thu, Sep 15, 2011 at 11:17 AM, Michal Suchanek <hramrach@centrum.cz> wrote:

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

[Robert_K1 (Robert K.)]

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 `<main>'
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 `<main>'

Kind regards

robert

···

On Thu, Sep 15, 2011 at 11:50 AM, Wayne Brissette <waynefb@earthlink.net> wrote:

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

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/