Nelvin Driz

Object Oriented Shell

Terminals — whether they be DOS or Bash — have always been a part of every developer’s life. I admit that I am no expert when it comes to Bash and Linux. This is why like most other people, newbies and intermediate level users, I tend to have a hard time scouring my way through the in and outs of a Linux-based system. How many times have we found ourselves seeing commands like these:

$ command | tail | head | cut | grep
$ alias hello='echo "' "'world'" '"' # Outputs(with double quotes) => "world"

The first example concerns slicing and dicing the output of the ‘command’. This will essentially format the output to make it readable for the user or to make it usable as an input by another command. On the other hand, the next example just shows a scenario that requires some special quoting. This seemingly simple task requires you to keep track of more quotes than you initially expected.

That is where Object Oriented Shell comes in.

But Why?

The current communication method of Bash commands with each other is limited to the text output produced. As discussed above, we would need to format these outputs so that they can be used by other commands. In addition, Bash in general is ‘hackish’ in nature. It is cryptic with commands like ‘ls’ and ‘ps’. Not to mention, each of these commands include various options. This would be troublesome for many who don’t have time to search the net or look at the ‘man’ pages. At the end of the day, Bash might be simple and quick at first, but as your task becomes more complex, the difficulty of implementing it exponentially rises.

Not New!

Object oriented shell is not new. Although it is said to be possible in Bash, it requires great amounts of effort and time to implement. So let us discuss some of those that I had found:

Fake (through Aliases)¹

Now who in the right mind would want to lengthen the command ‘ls’ to something like ‘dir.list’. Even though the latter is easier to understand, I suppose it is basic enough to be omitted or eventually shortened back to simply ‘ls’.

Interactive Ruby (irb)

Interactive Ruby is obviously not really made to be an object oriented shell. It is simply something for Rubyists to play around with so that they can learn and cultivate their know-how of the Ruby language. Nevertheless, it does enable you to interact with the system through various commands and special syntaxes.

Rush (Power of Unix, Elegance of Ruby)²

Rush is as said in their main website, “a replacement for Unix shell which uses pure Ruby syntax.” Unfortunately, it is not entirely something that most developers would want to replace their Bash with. It is more like a specialized interface to manage the system for certain tasks, most of which are described in their website. Basically, it requires people to really learn a whole new way of interacting with the system instead of extending what they had learned so far with Bash.

Another reason for not liking Rush is that it is not aware of any current directory. Instead, you have predefined locations like ‘home’. And in this directory, to access further sub-folders, you are required to type longer than usual commands. To really understand what I mean, an example is shown below.

rush> folder = home['Hello/World']
=> localhost:/Users/user/Hello/World
rush> folder.ls
/Users/user/Hello/World/
  fileX

Compared to Bash that is…

$ cd Hello/World
$ ls
fileX

The difference might not be such a big impact to the usual command line navigation. But small things do count especially for small tasks as this. Eventually you’d get tired of typing these long commands again and again just to navigate through your file system.

Rumba (Where Ruby meets Bash)

So I propose something not entirely different but pretty difficult.

Goals

• To extend Bash by creating a layer on top that would allow interaction with the system as objects, all the while still allowing most of the usual Bash commands to be used seamlessly.
• To gain a more verbose and readable output and commands so that new comers to Bash, especially those with a programming background, would feel more at home.

Challenges

• Grammar would definitely be a challenge since we are essentially trying to fuse two language syntaxes together.
• There are a lot of commands that needs to be covered before we can really say that Rumba can be a replacement to Bash.

Procedure

Of course coming from a Ruby background I would personally implement it using Ruby. But we need to draw a line between the two syntaxes so that they can live with each other. I got the idea from Vim, Modal Interfaces³, although it is more of an inspiration rather than an actual re-application of the concept. The idea is to have a special marker that allows the interpreter to identify how it will read a line. This special marker I am suggesting is the usual Dot Operator (.) which we use to signify that the succeeding characters would serve as the message that would be sent to the object.

Conceptual Shell Interaction

# Variable Assignments
$.@x = 1
=> 1
$.@x + @x
=> 2

# Environment Variables as Global Variables
$ $path
=> /usr/local/sbin:/usr/local/bin

# Execute Bash
$ ls
folder1 folder2 file.txt

# Bash Command as Object
$ ls.find :all
. .. folder1 folder2 file.txt
=> [#, #, #, #, #]

# EXTRA: Ruby State
$ ruby.do
001 > def hello_world
002 >  puts 'hello world'
003 > end
004 > hello_world
005 > ruby.end
hello world
=> nil

Final words

In the end, this is just an idea or rather an experiment. This challenging task might also be the reason why object oriented shell hasn’t been taken into mainstream yet. But in the end as well as more importantly, what do you think? Feel free to contact me or drop by the github repo — https://github.com/Keoven/rumba

Sources

¹ http://mediakey.dk/~cc/bash-shell-object-oriented/
² http://rush.heroku.com/
³ http://blog.cflewis.com/the-great-vim-textmate-debate-opinion-56