Rubish: A Unix shell written in pure Ruby

I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to, meaning I'll either have to install it (and it's not lightweight currently), or I'll have to live in two different worlds, which isn't usually sustainable.

Kudos though, and great work! I can tell you put a lot of thought and effort into it.

I'm recently seeing more and more Ruby projects that are at least partly vibe-coded, and I'm kind of torn. On the one hand I appreciate that this allows people to create stuff that they maybe wouldn't have the time to do otherwise. On the other, the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents.

A random example:

https://github.com/amatsuda/rubish/blob/master/lib/rubish/pa...

Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it? Does this mean you have to use a coding agent in order to contribute? I felt the same about the recent Ruby compiler from matz [1]. The code looks impenetrable. What does this bode for the future of OSS?

[1] https://github.com/matz/spinel

Tangential:

I would love to see more interpreted languages offer shells with native constructs for operating as daily drivers shells (not just REPLs). When I first started learning Ruby I used `rush`[0] as my main shell. Being immersed in the language, even if there were a few helpers for shell operations, really helped me reason better about Ruby and think in the language. `scsh`[1] was enlightening as well. Ultimately the ergonomics of both pushed me back to more conventional variant but they were really helpful learning mechanisms.

0: https://github.com/adamwiggins/rush 1: https://github.com/scheme/scsh

I have been unironically waiting for someone to properly implement something like this. Perfect way to use method_missing in Ruby.

People think Ruby is a slow language, but little do they know Ruby is a slower language than Go. But ruby these days is faster than Python.

Oh my god this is the best name to the application. You win the weekend.

Akira showed me this work in progress in January and I was pretty amazed by it, but I have to be honest—as someone who prides himself on clever OSS repo names, he just absolutely put me to shame. English as a second language but he's a first class punner.

Missing: size, speed comparsion with Almquist shell

This is probably even slower than bash

Great name though

Wow this is so tempting!

As an avid Rails Console (basically an application-aware Ruby REPL) user, this seems familiar. Nice work.

Usually when I see a project flaunting its language like this it elicits a sigh. (You probably know what I am talking about.) This is a happy exception since this project actually promotes a deep integration with its language of choice, so the title and name are fully warranted. Kudos for that.

A+ name, no notes

Upvoted just for the name.

Is it just me of did others also read rubbish instead of rubi-sh...I think that might be the joke. hm...

I much prefer the pipe to method chaining.

Very clever name!

I write a horrifying amount of PowersHell and I've always been craving something like that - rather than pwsh reinventing every wheel, just "bash but also with objects".

I have to confess, seeing Claude as a contributor made me sigh, but I still skimmed through and it looked quite thorough and well thought out. So, I don't know if this sits on the thin line between a vibe coded project and an LLM assisted project.

Cool project!

Just for fun, looking at code count as a rough measure of complexity.

rubish: 26,842

rc (plan9 shell): 5,888

To be fair, rubish does a lot more than rc. rc is pretty minimal.

rc source:

https://github.com/9front/9front/tree/front/sys/src/cmd/rc

Measures below:

    $ wc -l `find . -name '*.rb'`
      1124 ./rubish/execution_context.rb
        43 ./rubish/frontend.rb
      260 ./rubish/builtins/hash_directories.rb
      510 ./rubish/builtins/echo_printf.rb
      834 ./rubish/builtins/bind_readline.rb
      182 ./rubish/builtins/directory_stack.rb
      299 ./rubish/builtins/read.rb
      324 ./rubish/builtins/trap.rb
      129 ./rubish/builtins/arithmetic.rb
      862 ./rubish/completion.rb
      988 ./rubish/expansion.rb
      431 ./rubish/completions/git.rb
      114 ./rubish/completions/ssh.rb
      530 ./rubish/completions/bash_helpers.rb
      453 ./rubish/completions/help_parser.rb
      167 ./rubish/ast.rb
        46 ./rubish/frontend/tty.rb
      1179 ./rubish/runtime.rb
      127 ./rubish/lazy_loader.rb
        63 ./rubish/data_define.rb
      1163 ./rubish/runtime/command.rb
      153 ./rubish/runtime/job.rb
      7270 ./rubish/runtime/builtins.rb
      306 ./rubish/config.rb
      2442 ./rubish/repl.rb
      1316 ./rubish/codegen.rb
      1180 ./rubish/lexer.rb
      742 ./rubish/history.rb
      1169 ./rubish/parser.rb
        67 ./rubish/startup_profiler.rb
      848 ./rubish/prompt.rb
        47 ./rubish/data/readline_config.rb
      716 ./rubish/data/builtin_help.rb
      251 ./rubish/data/shell_options.rb
        53 ./rubish/data/completion_data.rb
        5 ./rubish/version.rb
      248 ./rubish/shell_state.rb
      140 ./rubish/arithmetic.rb
        61 ./rubish.rb
    26842 total

    $ wc -l *.c *.h *.y
      547 code.c
    1173 exec.c
      234 getflags.c
      259 glob.c
      240 havefork.c
      137 here.c
      301 io.c
      436 lex.c
      169 pcmd.c
      78 pfnc.c
      494 plan9.c
      539 simple.c
      74 subr.c
      37 trap.c
      190 tree.c
      420 unix.c
      109 var.c
      85 exec.h
      72 fns.h
        7 getflags.h
      28 io.h
      167 rc.h
      92 syn.y
    5888 total

Hmm. The name is a bit awkward since people can call it "rubbish". The idea is also not quite new in that many years ago people worked on an ruby-like shell with OOP support from the get go and they used a ncurses drop down box too. I forgot the name, but it must have been before 2010 already, as I vaguely remember it from talking on IRC back in those days. I think the main developer was from South Africa, but I don't remember that much anymore.

A few years ago irb got a facelift, so rubish probably represents a more modern take on the shell concept. I tested it and it works too. I wonder how much the everything-is-an-object idea is extended here. Many years ago I learned avisynth + virtualdub and I always liked how they approached filtering. Ffmpeg is great, but I absolutely hate the filter system it uses and the ABSOLUTELY horrible syntax. The ffmpeg devs do not seem to know avisynth, or any alternatives here - so I want object manipulation with a convenient syntax at all times, not just for audio/video data but literally for any data. Naturally ruby would be a good fit by default, but I am unaware of many ruby developers even wanting to go that route. If there are still any ruby developers left that is - ruby has been tanking hard in the last few years, approaching extinction level, just like perl did before.

There has to be a better influx of new users; the old +50 years generation isn't going to keep languages alive really.

Edit: Also I forgot: the idea and implementation is fine, I just think we need much more of that in general. Ruby is kind of in a patchy patchwork situation. Where are the epic projects? Rails is also ancient already.

[dead]

Good April 1 article.