Yes, it’s possible to execute a Ruby script from Rails. Please remember
that Rails is implemented in Ruby and you can use an method called ‘system’.
Good luck,
-Conrad
Hi there,
now i tried to execute via System-Command but i just can catch the value
true/false.
Are you doing something like this?
exit_status = system( <some_command>)
Is it possible to declare a global variable in my ruby script - execute
the script - and then catch it with rails?
Yes, it’s possible to declare a global variable within your script. I would
recommend getting yourself a copy of “Programming Ruby” as a desk-side
reference.
Good luck,
-Conrad
What you are looking for is the backtick '`' method of Kernel, aliased as %x(). You should refer to the official api at Index of Files, Classes & Methods in Ruby 3.1.2 (Ruby 3.1.2) and read this carefully.
Rails is a framework not a programming language. So it is really a default directory layout supported by a vast amount of clever code to do most of the grunt work required to write web apps. As other have pointed out, Ruby is the language used. To run one Ruby script from another your would have something that looked like this, more or less.
caller.rb #!/usr/bin/env ruby # call the other script and open an new shell %x(path/to/my/other/script.rb) #eof
script.rb #!/usr/bin/env ruby puts "script.rb has been called" #eof
Now, this will display nothing because the stdout of the target script is not looked for in the calling script, which is the one you ahve open in your console. So:
caller.rb #!/usr/bin/env ruby # call the other script and open an new shell my_stdout = %x(path/to/my/other/script.rb) puts my_stdout #eof
That should display the output of script.rb on the console running caller.rb. script.rb's stderr can be redirected as well:
caller.rb #!/usr/bin/env ruby # call the other script and open an new shell my_stdout = %x(path/to/my/other/script.rb 2> &1) puts my_stdout #eof
HTH
James Byrne wrote: [...]
What you are looking for is the backtick '`' method of Kernel, aliased as %x().
[...]
This shells out just like system() does. It's a good general method of running arbitrary shell scripts in other languages, but it should not be necessary when the scripts are in Ruby. Integrate instead of shelling out.
[...]
To run one Ruby script from another your would have something that looked like this, more or less.
caller.rb #!/usr/bin/env ruby # call the other script and open an new shell %x(path/to/my/other/script.rb)
No. You'd be better off using require or similar.
Best,
Marnen Laibow-Koser wrote:
James Byrne wrote:
No. You'd be better off using require or similar.
That really depends upon the question being asked. The OP explicitly asked on how to run an external script, that happened to be written in Ruby; not, what is the best way to run arbitrary external ruby code from inside a running Ruby script?
If the latter case then I suggest that the OP consider this approach, which was recently shown to me by Matt Wynne on the Cucumber list:
First, write the script and encapsulate its entire code within an execute method contained in a Script class file. Like so:
script.rb class Script # should be the actual name of the script. def initialize(argv) # receive the ARGV array from the calling process @argv = argv end def execute # if required then parse any command line arguments in @argv here puts "script.rb called" end end #eof
If a stand-alone script initiation is required, as with cron say, then write a stub script that calls the script class and executes the script code like so:
runner.rb #!/usr/bin/env ruby require 'script'
Script.new(ARGV).execute #eof
If the encapsulated script is complex enough that it contains its own internal classes then the whole can be encapsulated inside an outer class given the script name. The inner class containing the execute method is then renamed to something like Main. In this case the call becomes:
Script::Main.new(ARGV).execute
And the class file script.rb has this structure
class Script
class Main def initialize(argv) @argv = argv end def execute script code goes here end end
class OtherClass ... end end
One may now use the script within any other ruby process as you suggest, via a simple require and subsequent instantiation. I found this technique extremely valuable in testing since out of process scripts did not share the dbms state with the the test harness.