life.events.each { |event| learn_from(event) }

It turns out, RubyShell 0.2 ran code twice when you asked it to run it once. Whoops…

Anyway, once again that’s only one of the several new features (okay, that one was a bug fix, too…) in RubyShell 0.3. If you want to skip the explanation, you can go ahead and download it now or look at the list of fixed/implemented issues.

RubyShell 0.3 brings a couple of brand spankin’ new things to the table. The first is the validation process.

Parsing/Validation

Validation is the process whereby RubyShell validates code as being Ruby. If it isn’t Ruby, then it’s run as a command. Originally, this was done using the defined? keyword, which, while kind of awesome, unfortunately actually ran the code embedded within it, which I had originally thought was not the case. Fear not, however! I have fixed this. RubyShell 0.3 uses ParseTree to make a real attempt to parse the code without any side-effects. In addition, it brings a restructuring of the validation so that validation is handled in its own class, with the evaluation class (the RubyEvaluator class) acting as the Parser class’s conduit to the validator. Multiline Ruby is now handled by looking for syntax errors of a particular kind, which makes it far more flexible than the previous versions, and means RubyShell should be able to handle most multiline Ruby code.

As part of this, the validation includes exceptions for two common shell practices, the trailing / and the trailing ~. For example:

cd ~

This is technically a valid first line of Ruby, with the next line promising to be the other side of the complement operator. However, since it is more common in a shell to be using ~ as `my home directory’ than it is in Ruby to use the complement operator at the end of a line, this is simply considered invalid Ruby and will be run as a command. The same applies for a trailing /, which is commonly used on the end of a directory name, as in shadowfiend/ruby/.

CDs

The CdCommand got a few updates during this release. It now correctly handles tidle expansion (by using the handy File.expand_path method… Kickass method, that!), and running a `cd’ with no parameter is now synonymous to `cd ~’. It’s kind of awesome.

Pipes

Finally, and, for me, most awesomely, this release brings the improved piping syntax to RubyShell. This syntax lets you use $pipe as an implicit receiver for the first message of a line of Ruby code in a piped expression (actually, in any expression). For example, say you wanted to run an `ls’ and then print each line with a trailing `RubyShell rocks!’. In RubyShell pre-0.3, you would do¹:

ls | $pipe.each_line { |ln| puts "#{ln}RubyShell rocks!" }

Not horrendously ugly, but also not very pretty. RubyShell 0.3 still allows this syntax, of course; however, there’s a new one. Now, any calls to methods that start with with_ or and_ are assumed to mean `$pipe.’. The above example in done this way:

ls | with_each_line { |ln| puts "#{ln}RubyShell rocks!" }

There, doesn’t that look better? How about we want to have everything in the current directory, but we want to censor any mentions of `java’:

ls | and_gsub 'java', ''

Shiny, eh?

Other Fixes/Improvements

The presence of the new validator means a lot of validation-related issues were fixed for this release. Frederick Ros also provided a patch to fix RubyShell’s crashing shamelessly when you hit `enter’ with nothing on the line, ‘cause he’s just a fabulous person. Plus, now if a line of code wasn’t evaluated as Ruby and failed to run as a command, an error is printed. Some refinement need still be done—for example, printing an error is unnecessary if the command itself prints anything to stderr or stdout. Not sure how to determine whether that happened, though. It may be that the error will instead be printed if a valid command cannot be found. Again, however, this will be somewhat difficult to determine, since Kernel#system returns false whether that’s the case or the command just didn’t exit happily. Might be able to use the exit code for that.

Le Future!

Or, in Indo-Chinese², `the future!’ While I wanted to do output redirection for this release, I decided to shelve it for now so I could think out and research the syntax a little better. The feature issue tracking it is over here, and I already posted some initial thoughts on how I might do the syntax. Also on the list is better error handling—i.e., it would be nice if RubyShell didn’t die a horrible death when you made a syntax error in the code you typed.

Further out, there’s the idea of improving shell completion, though that’s really dropping further on the list the more I think about it, since having filename completion (which is already present) is really by far the most important thing for a shell. Also on the `indeterminate future’ list is an initialization file (~/.ruby_shellrc or something) and the ability to run actual files of RubyShell code. These two should be relatively simple, and the former depends on the latter. I also need to implement backtick notation (``), but making that basically interpolation of any RubyShell command, including regular Ruby. That’s all I can think of for now, but more ideas are welcome! And I’m sure I’ll come up with a few more of my own, as usual.

Enjoy!

---

¹ Actually, whether you would really do this is anybody’s guess, since RubyShell pre-0.3 handled blocks in piped expressions a little oddly, and would sometimes explode in a shower of fiery sparks.

² Really, that should have been `Sino-Indian’, if only to use `sino’.