Rush - OOP shell in Ruby

Posted by Mirko Stocker on Feb 27, 2008 12:15 PM

Community

Ruby

Topics

Deployment / Datacenter ,

Linux ,

Dynamic Languages ,

Scripting

Tags

Deployment ,

Languages

Rush - the Ruby shell - is an object oriented shell using the Ruby syntax. Object oriented means that you don't just manipulate and pass around strings but real Ruby objects with their own methods and attributes. So instead of ls -l /var, one can call the ls method of a directory object:

rush> root['/var/'].ls
 //var/
 db+
 lib+
 log+
 run+
 [...] 

 Rush is supposed to be a replacement for the most commonly used built-in commands and core-utilities of common Unix environments, with all the benefits of an object oriented programming language. But there's even more:

But rush is more than just an interactive shell and a library: it can also control any number of remote machines from a single location. Copy files or directories between servers as seamlessly as if it was all local.

We talked to Adam Wiggins, the developer of rush. Adam started working on it for his own needs: 

I've wanted a Ruby-syntax replacement for the unix shell from almost the moment I began using Ruby. Whenever I can, I write shell scripts as Ruby scripts with lots of backticks.

Object oriented shells aren't really a new idea, for instance Microsoft already ships its new .NET based Windows PowerShell with Windows Server 2008, which also served as an inspiration to create rush.

Ruby's powerful meta-programming abilities make extending rush quite easy. For example, lets extend Box (the representation of a single machine) with a method that returns the IP address. Customization happens in the .rush/env.rb file, so we can simply add our new method there:

class Rush::Box
 def ip_address
  bash("ifconfig | grep inet | grep -v 127.0.0.1").match(/addr:([\d.]+)/)[1]
 end
end  

Back in rush, the following should now print your local IP address:

rush> Rush::Box.new.ip_address
 192.168.1.104 

Wiggins already has some ideas on how to make other administration tasks like starting and stopping of services, database creation or iptables rules manipulation easier:

[...] netstat -lptn is awesome for figuring out what process is hogging a particular port, but it's difficult to combine it with other operations. In rush, you should be able to do something like: box.processes.each { |p| p.kill if p.listen_port == 3000 }

And about rush's long-term goals:

Reimplementing the thousands of commands that live in /usr/bin (plus all the bash builtins) might seem like a daunting task. But I suspect that the vast majority of these are rarely used. A small subset, implemented well, could cover 80% of what I and other unixheads want to do - particularly in the realm of cluster management, which is what rush was really created for. rush's libraries are currently about 1500 lines of code, and already it covers most of the major file and process operations. I'm thinking it should be possible to cover almost everything I ever want to do in managing a unix system in around 10k lines of code.

For more on rush, check rush's official website or join the rush Google Group. Note that the ruSH project on RubyForge is a different project and doesn't seem to be alive anymore.

1. Back to top

   Great stuff , but why shell?

   Feb 27, 2008 12:37 PM by Sergei Rogovskiy

   In my opinion shell assumes user typing commands in the terminal window. In this sense, typing 6 lines to remove folder on remote machine doesn't make much sense compared to ssh root@blah -c 'rm -rf /test' , nor root['var'].ls vs 'ls /var' .
   
   From the other hand it is very cool extension to write system administration scripts in ruby , which I've being missing for long time.
   
   Way to go , rush

   Reply

2. Back to top

   Re: Great stuff , but why shell?

   Feb 27, 2008 4:05 PM by Francois Ward

   OOP shells are almost always made to make administration scripts, especially reusable ones, or to make scripts that will have a GUI front end. Windows Powershell works like that (using .NET as the backend). Though it is still semi-friendly to the command line, especially if you make your own cmdlets.

   Reply

• Older >