Some questions about Ruby and it's environment

I have two issues in Ruby which are bugging me.

On my (MS Windows) system, I have a couple of programs to help me 

live
my electronic life and some of them are written in Ruby (are they still
called “programs” or are they “scripts?”). I keep all these programs in
a
directory and have an execution path to them.
I also have some patterns that come up time and time again in my
Ruby
code so I have factored them out into their own files so I may “require”
them in any of my Ruby scripts.
The problem is that Ruby can’t find them. I had hoped that Ruby
would
search for “required” files in the directory of the running script but
this
doesn’t appear to be the case. I could have used the magic “$0”
variable
but then I’d have to operate on it before using it. I also considered
refactoring this work and using that but…
Is there anything I can do to get Ruby to find these “required”
scripts?

My second issue is not very serious but a curiosity to me.  I used 

to
use PERL so some of my useful “programs” are still written in that
language.
I tried to call a PERL script from a Ruby script and that myseriously
failed. I did a search on groups.google and found that you need to call
the
PERL interpreter, directly. I found this a little odd since PERL
scripts
have no problem calling other PERL scripts. It’s not a problem of the
environment, since Ruby can call executables in the execution path.
So, what’s up with that? Why isn’t the Ruby interpreter like PERL
in
this respect?

Thank you for your help!

On Jul 14, 2006, at 6:55 PM, Just Another Victim of the Ambient
Morality wrote:

On my (MS Windows) system, I have a couple of programs to help me
live my electronic life and some of them are written in Ruby (are
they still called “programs” or are they “scripts?”). I keep all
these programs in a directory and have an execution path to them.

I also have some patterns that come up time and time again in my
Ruby code so I have factored them out into their own files so I may
“require” them in any of my Ruby scripts.

Are those files in ruby’s load path?

The problem is that Ruby can’t find them. I had hoped that Ruby
would search for “required” files in the directory of the running
script but this doesn’t appear to be the case.

Ruby does not.

I could have used the magic “$0” variable but then I’d have to
operate on it before using it. I also considered refactoring this
work and using that but…

Is there anything I can do to get Ruby to find these “required”
scripts?

Ruby searches these paths:

ruby -e ‘p $LOAD_PATH’

You can use the -I argument or the RUBYLIB environment variable to
add paths to this. You can also put your extra libraries in your
site_ruby directory.

I tried to call a PERL script from a Ruby script and that myseriously
failed. I did a search on groups.google and found that you need to
call the PERL interpreter, directly. I found this a little odd
since PERL scripts have no problem calling other PERL scripts.
It’s not a problem of the environment, since Ruby can call
executables in the execution path.

I don’t believe you. Please show us an error.

$ cat x.pl
#!/usr/bin/env perl

print “hi\n”;

$ ruby -e ‘system “./x.pl”’
hi


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

Eric H. wrote:

“require” them in any of my Ruby scripts.

Are those files in ruby’s load path?

The problem is that Ruby can’t find them. I had hoped that Ruby
would search for “required” files in the directory of the running
script but this doesn’t appear to be the case.

Ruby does not.

Well, it does look in the directory from which the script is run, which
is not necessarily where the script is located.

I could have used the magic “$0” variable but then I’d have to
operate on it before using it. I also considered refactoring this
work and using that but…

Is there anything I can do to get Ruby to find these “required” scripts?

Ruby searches these paths:

ruby -e ‘p $LOAD_PATH’

And the directory the scripts is started in shows up in that array as
‘.’

I don’t believe you. Please show us an error.

$ cat x.pl
#!/usr/bin/env perl

print “hi\n”;

$ ruby -e ‘system “./x.pl”’
hi
This is on Windows…maybe that makes a difference in this case? I don’t
know that Windows respects the #!
(I have no idea, I don’t do any programming in Windows)

-Justin

“Eric H.” [email protected] wrote in message
news:[email protected]

paths to this. You can also put your extra libraries in your site_ruby
directory.

Thanks, I went with the environment variable.  It's what I was 

looking
for…

#!/usr/bin/env perl

print “hi\n”;

$ ruby -e ‘system “./x.pl”’
hi

Interestingly enough, I remember seeing this on the other post in 

this
newsgroup. This is what this scenario looks like for me:

$cat x.pl
print “hi\n”

$ruby -e ‘puts x.pl
-e:1:in ``': Exec format error - x.pl (Errno::ENOEXEC)
from -e:1

Of course, in DOS, the command line uses the ">" symbol but I didn't

want to create any confusion with quoted text. Of course, the solution
was
to use the “system” method but, really, what’s so different with the
familiar `` operator? …Yet you didn’t know this nor did you use it in
your example. This suggests to me that you don’t use this operator
anymore.
Why not? The “system” call doesn’t even return the output of the
command
nor does this output actually reach stdout…

On Jul 14, 2006, at 10:41 PM, Just Another Victim of the Ambient
Morality wrote:

PERL

$ruby -e ‘puts x.pl
-e:1:in ``': Exec format error - x.pl (Errno::ENOEXEC)
from -e:1

Of course, in DOS, the command line uses the “>” symbol but I
didn’t want to create any confusion with quoted text. Of course,
the solution was to use the “system” method but, really, what’s so
different with the familiar `` operator?

Are you sure it worked with system?

try:

$ ruby -e ‘p system(“./x.pl”)’

You should see a hi and a true printed, something like this:

hi
true

The differences between ` and system shouldn’t be important for
getting this to work, I think Windows needs to know how to run .pl
files for this to work.

…Yet you didn’t know this nor did you use it in your example.
This suggests to me that you don’t use this operator anymore. Why
not?

I could have used , but chose not to. I use when I need to
capture stdout.

The “system” call doesn’t even return the output of the command nor
does this output actually reach stdout…

Well, it may not be running at all and returning false.

Do you have Windows mapping the perl interpreter to .pl files? What
happens when you double-click a .pl file from explorer?

A Windows expert may need to help you on this problem. Ruby just
asks the OS to run these things, so if the OS can’t figure out what
to do with it Ruby won’t be able to either. :frowning:


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

“Eric H.” [email protected] wrote in message
news:[email protected]

try:
to work.
Ah, indeed, system didn’t work. Windows does know how to execute PERL
files so this behaviour is curious…

…Yet you didn’t know this nor did you use it in your example. This
suggests to me that you don’t use this operator anymore. Why not?

I could have used , but chose not to. I use when I need to capture
stdout.

Is it faster not to capture output if you don't need it?

The “system” call doesn’t even return the output of the command nor does
this output actually reach stdout…

Well, it may not be running at all and returning false.

This is, in fact, the case.  The following works:

ruby -e ‘system “perl x.pl”’

...which, again, shows that Ruby (or Windows) can search execution 

paths
for things to execute. It seems clear that something, somewhere, is
having
trouble associating .pl files to the PERL interpreter. Indeed, simply
executing “x” (without the extension) on the command line doesn’t work,
so
this might show evidence of that. However, if x were a ruby script,
executing that on the command line would work! Yet, it won’t if
passed to
the “system” method, even if we were to add the extension. So,
something is
quite different between the command line and the Ruby “system” method…

Do you have Windows mapping the perl interpreter to .pl files? What
happens when you double-click a .pl file from explorer?

It launches a DOS command window with the script executing...

A Windows expert may need to help you on this problem. Ruby just asks
the OS to run these things, so if the OS can’t figure out what to do with
it Ruby won’t be able to either. :frowning:

I think you may be right.  This looks like it's either a peculiarity 

of
MS Windows or of the Win32 implementation of Ruby…
Thanks for your input!

Just Another Victim of the Ambient M. wrote:

I'm pretty sure the "#!" line is meaningless on Windows and the shell 

doesn’t even bother looking for it.

The shell doesn’t. (However, Apache, when running under Windows, does,
just to freak out newbies, I half-suspect.)

John W. Kennedy wrote:

Just Another Victim of the Ambient M. wrote:

I'm pretty sure the "#!" line is meaningless on Windows and the 

shell doesn’t even bother looking for it.

The shell doesn’t. (However, Apache, when running under Windows, does,
just to freak out newbies, I half-suspect.)

But it’s configurable if you want Apache to use the Windows-associated
application to execute CGI scripts.


James B.

“Discover the recipes you are using and abandon them.”

  • Brian Eno and Peter Schmidt, Oblique Strategies

Just Another Victim of the Ambient M. wrote:

The Windows command line certainly knows how to execute scripts (via

“file associations” based on the extension) so I think it’s up to Ruby to
take advantage of this information, if possible…

However, the .rb file extension is associated with Rocket eBook Reader.
So anything that expects this extension to always work in Windows can
run into odd results.

Another reason why file extension is a cruddy indicator of file
metadata, but that’s the legacy we have from DOS…

On Jul 15, 2006, at 5:10 PM, Just Another Victim of the Ambient
Morality wrote:

The Windows command line certainly knows how to execute scripts  

(via
“file associations” based on the extension) so I think it’s up to
Ruby to
take advantage of this information, if possible…

I believe you want system(“start x.pl”) or system(“start blah.rb”)

On Sat, 15 Jul 2006 21:06:25 +0000, Just Another Victim of the Ambient
Morality wrote:

I'm pretty sure the "#!" line is meaningless on Windows and the shell 

doesn’t even bother looking for it. Indeed, it always struck me a little
weird that every script knows exactly where the interpreter image is. What
if it were to move? All your scripts will suddenly break! An annoying,
albeit, unlikely scenario…

#!/usr/bin/env perl
#!/usr/bin/env ruby
… etc

env finds the interpreter wherever it is and runs it, as you’d expect.

A neat trick, I don’t know why it isn’t used, well, universally.

Of course it relies on env being in /usr/bin but, that changes less
(never) than where particular interpreters are.

“Justin C.” [email protected] wrote in message
news:[email protected]

This is on Windows…maybe that makes a difference in this case? I don’t
know that Windows respects the #!
(I have no idea, I don’t do any programming in Windows)

I'm pretty sure the "#!" line is meaningless on Windows and the 

shell
doesn’t even bother looking for it. Indeed, it always struck me a
little
weird that every script knows exactly where the interpreter image is.
What
if it were to move? All your scripts will suddenly break! An annoying,
albeit, unlikely scenario…

The Windows command line certainly knows how to execute scripts (via

“file associations” based on the extension) so I think it’s up to Ruby
to
take advantage of this information, if possible…

On Aug 1, 2006, at 9:15 PM, Scheming C. wrote:

albeit, unlikely scenario…
(never) than where particular interpreters are.

When you use a line like #!/usr/bin/env ruby, env searches each
directory on your path for a program called ruby – but in some
situations, such as running under a web server like Apache or from a
remote ssh session, your path isn’t set, or is set to a restricted
subset of your normal path, so /usr/bin/env won’t find what it’s
looking for. As I understand it, that’s why it’s not more universally
used.

For instance, on the web hosting service I often use Apache doesn’t
set any path at all, so while /usr/bin/env exists, it can’t be used
in this way.

– Brian

On Aug 1, 2006, at 8:15 PM, Scheming C. wrote:

albeit, unlikely scenario…
(never) than where particular interpreters are.
cron does not set PATH, so scripts with this #! won’t work.


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

On 8/2/06, Scheming C. [email protected] wrote:

… etc

env finds the interpreter wherever it is and runs it, as you’d expect.

A neat trick, I don’t know why it isn’t used, well, universally.

Of course it relies on env being in /usr/bin but, that changes less
(never) than where particular interpreters are.

however, on some platforms /usr/bin/env is broken. Not to mention the
occasions when there are several interpreters installed.

Thanks

Michal