Have you ever used Ruby just by itself?
|
|
In the 90's and early 00's, when Ruby was starting to become popular, it was mostly as a language for sysadmins to write short scripts and CLI tools to automate their work. Ruby still maintains a lot of features and bells and whistles from this era, many of which are still very useful to Rails developers.
Let's talk about three useful ways to use `ruby`, that is, the command line ruby executable. As Rails devs, we're pretty used to just using tools built with Ruby, but not actually running the Ruby executable itself. That's a shame - Ruby is a great CLI tool, and the executable has some cool features that are still useful for Rails devs today.
Running Single Files with -I
Most Rails developers I know are pretty used to working inside of a Rails environment. They only use executables like `rails`, `rake`, and `rspec`. This means that a lot of the way that Ruby and Bundler loads code is abstracted away, and you're used to certain classes and gems being available in your code, but you don't know how they get there.
This leads to an atrophy of basic Ruby knowledge that manifests in problems like not knowing how to run a single test file with Minitest. Yes, you know how to `rake test`, which runs the whole suite, but what about running just a single file?
Minitest is really simple. If you require `minitest/autorun`, Minitest will install a hook when the program tries to exit that runs all of your tests. So, to run a single test file with Minitest, we just have to require the files that contain the tests we want to run, and then require minitest/autorun. Usually, minitest/autorun is required in a "test helper" file which is required at the top of the test file.
So, running `my_test.rb` will require `test_helper.rb`, which then requires `minitest/autorun`, running our tests at exit.
So "ruby my_test.rb" should work, right?
It doesn't. Most test helpers don't modify the load path and assume that `require lib/my_code` will work. Try to run a single test with ruby my_test.rb, and it blows up.
This is where the `-I` option comes in.
This is how I run tests in Puma every day. ruby -I lib my_test.rb. Ta-da! Modifying the load path with -I means that "require puma/whatever" will work just as if we had run all the tests with rake test.
Piping Ruby with -e and -n
You can evaluate Ruby on the command line with the -e option.
$ ruby -e "puts 'Hello World'"
Hello World
Now, where this gets fancy is when you start using this with pipes. Ruby can actually be subsituted for awk or sed. Adding the `-n` flag essentially puts a loop around your `-e`:
while gets
# whatever is inside -e goes here
end
... which makes it perfect for piping over input. Recall that $_ is the special global variable for "the last line read from STDIN".
$ echo 'Hello World' | ruby -n -e 'puts $_.upcase'
HELLO WORLD
If you ever wondered why Ruby has all of those weird global variables like $!, etc - these use cases are why.
Running a webserver
This line is in my .bash_profile:
alias serve="ruby -run -ehttpd"
It's so simple, but so useful - it serves the current directory up on port 8080 over HTTP. Very useful for testing flat/static site output.
That was three little CLI tricks with the Ruby executable. I hope you've learned something!
-Nate
|
|
|
|