Some questions about Ruby and it's environment...

[Just Another Victim of the Ambient Morality]

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!

 

[Eric Hodel]

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

 

[Just Another Victim of the Ambient Morality]

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.

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

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

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

 

[Justin Collins]

Are those files in ruby's load path?


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.

Ruby searches these paths:

ruby -e 'p $LOAD_PATH'

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

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

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?

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.

 

[Just Another Victim of the Ambient Morality]

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.

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

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?

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.

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

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

 

[John W. Kennedy]

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

 

[James Britt]

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.

 

[S Wayne]

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

 

[Logan Capaldo]

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

 

[Scheming Commie]

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.

 

[Brian Palmer]

#!/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.

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

 

[Eric Hodel]

#!/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.

cron does not set PATH, so scripts with this #! won't work.

 

[Michal Suchanek]

#!/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.

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

Thanks

Michal