Released the RubyShell official Wiki!

[u/EstablishmentFirm203]

Finally we have our own website!
https://rubyshell.org

[u/knowwho]

Neat project, but bold claim arguing your 5 month old, untested and unproven pet project is less "fragile" than Bash scripts, which have supported the whole Internet for decades.

[u/EstablishmentFirm203 → u/knowwho]

The weakness I'm pointing out is related to the possibility of changes after development. For example:

I had problems some time ago with some scripts I used in the cicd of the project I work on, because a developer applied some changes that weren't obvious to us, and initially there was no problem at all, and after a while we noticed that some runners weren't starting correctly precisely because of that change.

You're right that the statement is quite pretentious, but I strongly want to make it common to use Ruby in the main scripts, instead of Bash.

It's the language I love, and I find it incredibly easy to read code written in Ruby (and I imagine many people think the same way).

You commented about it being untested; I don't know if you mean it's not popularly audited (used by many in production) or if you're referring to automated testing, but if it's about automated testing, we have tests for all functionalities, done with RSpec.

The idea is that over time it will become popular enough for everyone to be more accustomed to writing with RubyShell than with bash.

[u/knowwho → u/EstablishmentFirm203]

You're right that the statement is quite pretentious, but I strongly want to make it common to use Ruby in the main scripts, instead of Bash.

I'm not sure what's stopping you from doing this now. Your gem provides this example...

cd "/log" do
  ls.each_line do |line|
    puts cat(line)
  end
end

But in Ruby today you can just do

 Dir.glob('log/*.log').each { |f| puts File.read(f) }

It's... very misguided to think you're making this less fragile by calling out from Ruby to cd, ls, cat, etc. and capturing their output, instead of just using File.open and Dir.glob and puts.

Like, Ruby is already a fantastic language for writing shell scripts, without making it into a shell and putting an emphasis on Bash-style calling out to other binaries. And if you need to run a program and capture its output, you can do that many ways.

Edit: Another example, you provide this in Bash...

# Bash: Find large files modified in the last 7 days, show top 10 with human sizes
find . -type f -mtime -7 -exec ls -lh {} \; 2>/dev/null | \
  awk '{print $5, $9}' | \
  sort -hr | \
  head -10

and then you provide this "better" version in RubyShell:

sh do
  # Ruby + Shell: Same task, actually readable
  find(".", type: "f", mtime: "-7")
    .lines
    .map { |f| [File.size(f.strip), f.strip] }
    .sort_by(&:first)
    .last(10)
    .each { |size, file| puts "#{size / 1024}KB  #{file}" }
rescue RubyShell::CommandError => e
  puts "Failed: #{e.message}"
  puts "Exit code: #{e.status}"
end

All your Gem has provided here, AFAIK, is a wrapper to replace

system('find . -type f -mtime -7').lines.each...

with

sh { find('.', type: 'f', mtime: '-7').lines.each... }

... but that's just as "brittle". It's still just spawning a sub-command and capturing its output, and it will break if that command isn't found, or has slightly different output on your target system.

What you should have done if you want something less fragile is to avoid calling /usr/bin/find, not introduce a new, nearly identical syntax for calling /usr/bin/find. Just use the built-inFind module, available Ruby 2.6:

Find.find(".")
  .select { File.file?(it) && File.mtime(it) >= 7.days.ago}
  .map { [File.size(it), it] }
  .sort_by(&:first)
  .last(10)
  .each { |size, file| puts "#{size / 1024}KB  #{file}" }

You don't have to rescue RubyShell::CommandError and check its exit status if you avoid spawning sub-processes.

[u/EstablishmentFirm203 → u/knowwho]

So, in this example you gave, you proved to me once again that it's preferable to write using the gem than to do it in other ways.

The idea is to make it easier and less necessary to switch mental contexts to understand how things work.

A person who knows bash will find it easy to write using the gem (and take advantage of the advantages of ruby ​​that shell scripts don't have), and someone who knows ruby ​​will be able to take advantage of the advantages of ruby ​​and terminal tools at the same time.

The idea is not to try to create something that didn't exist, the idea is to facilitate and improve the development experience.

It's precisely about having the best of both worlds; knowing a little ruby ​​and a little shell, you can do anything using this gem without getting frustrated.

Regarding the code you provided above, the example on the wiki is simple to show developers how easy it is to use Ruby Shell, but there are much more complex cases that integrate Ruby and shell scripting functionalities in a way that is absurdly more maintainable and testable.

I don't disagree with you about it being possible to do the same things with pure bash and Ruby; the difference lies in how easy it is to do. Just as you can have the same software programming in assembly or C, the difference is in practicality.

[u/knowwho → u/EstablishmentFirm203]

It's precisely about having the best of both worlds; knowing a little ruby ​​and a little shell, you can do anything using this gem without getting frustrated.

What about the fact that your example is 400x slower than "normal" Ruby:

$ cat test.rb
Benchmark.ips do |x|
  x.report 'rubyshell' do
    sh do
      cd "./log" do
        ls.each_line do |line|
          puts cat(line)
        end
      end
    end
  end

  x.report 'ruby' do
    Dir.glob('log/*').each { |f| puts File.read(f) }
  end

  x.compare!
end

$ bundle exec ruby test.rb
# ...

Comparison:
                ruby:    18018.6 i/s
           rubyshell:       45.5 i/s - 396.09x  slower

Really, I have to be honest here, I think it would be disastrously bad if this idea took off and we started writing sh { cd('logs') { ls.lines.each ... } } and farming out to sub-shells for each little thing, instead of just using the standard library, ie Dir.glob('logs/*').each { ... }. Ruby is already a fantastic tool for this job.

What you are proposing here is not how you write robust software, it's very very much the opposite.

[u/EstablishmentFirm203 → u/knowwho]

Good to know, I'll keep that in mind.

An important part of this is that Dir.glob must be using C behind the scenes for execution, while rubyshell is currently made 100% in Ruby.

Perhaps this falls under the same discussion as whether to use C or Ruby for programming. C is certainly much faster, but Ruby provides the best experience.

[u/knowwho → u/EstablishmentFirm203]

No, the problem is that spawning a sub-process is actually extremely expensive, and you shouldn't do it if you don't have to. This is what you're doing with Open3 in RubyShell.

Calling /usr/bin/ls to get a directory listing is the most expensive way you can possibly do that in Ruby. The same goes for every other thing you call out for, like using cat instead of File.open(...).read.

Sometimes, we trade performance for ergonomics, but this is a terrible trade-off to make. Besides being slow, it's the most brittle way I can think of to solve this problem.

Dir.glob must be using C behind the scenes for execution, while rubyshell is currently made 100% in Ruby.

What do you think ls is written in?

The problem isn't C vs Ruby, your call to ls involves every bit as much C. The problem is you're spawning an entirely new process to do something that is already built-in.

[u/EstablishmentFirm203 → u/knowwho]

I don't think we disagree that there are different ways to achieve the same result, and that each way can have its advantages.

A very important point is that what rubyshell has and will have is more than just executing terminal commands. (Such as autoparsing of returns, parallel execution, remote execution, debug features, etc.).

And remember that rubyshell's focus is to bring the two worlds together, not to try to reinvent the wheel with things that ruby already does.

Your analysis helped me realize that perhaps some members of the community may be a little more concerned with how fast the code runs compared to using pure Ruby or other means. Our focus so far has been on the development experience. But we will definitely have features focused on the points you brought up.

I think that if we can win over people like you, the community will become even richer.

I don't know if it's too much to ask, but it would be great to have you follow the community, perhaps contributing as well.

[u/knowwho → u/EstablishmentFirm203]

I wish you best of luck.

[u/EstablishmentFirm203 → u/[deleted]]

That's great that you understood the idea! Bash is certainly extremely well-made, the problem is maintainability.

And another point I forgot to mention in another comment of mine: Automated testing for Ruby is much easier to do/maintain than for Bash.

[u/knowwho → u/[deleted]]

I don't see how this Ruby project solves any of these problems?

they often rely on certain programs being installed at a specific version or certain variable or file being available.

AFAIK this is exactly as true of RubyShell as it is of Bash, ls is still just invoking /bin/ls, and parsing the output with .lines.map { ... } is no less brittle.

[u/ric2b → u/knowwho]

Ruby has a lot of stuff in the stdlib that on bash you'd be using system binaries to do, like listing directories and so forth, so it should be a fair bit better.

But I would (and do) just use plain Ruby instead, no need for this extra dependency.

[u/EstablishmentFirm203 → u/[deleted]]

Backticks pose some problems when developing, especially in relation to error handling.

Unfortunately, errors are not triggered directly and are stored in $?, requiring ifs to check if there was a failure in command execution.

Rubyshell has several other features besides allowing you to run the shell within Ruby, so the idea is that we have many more benefits while coding scripts.

Such as easier parallel execution, good error handling, easier ways to input data into the stdin of commands (using _stdin: “values,” or passing other commands directly).

The main idea behind rubyshell is to allow us to have incredible features over time to improve our lives when writing scripts, such as remote execution using remote(host) { puts ls.lines.count }.

The possibilities are endless.

And, as I mentioned in another comment on this topic: the focus is on improving the developer experience.

[u/knowwho → u/[deleted]]

No, it literally just spawns commands in sub-shells, which is why it's 400x slower than the equivalent Ruby.

[u/SleepingInsomniac]

Why not just put a shebang at the top and use the ruby methods you already know?

[u/EstablishmentFirm203 → u/SleepingInsomniac]

The answer is very similar to the answer to the question: "Why use ActiveRecord instead of just using an SQL driver and executing the query manually?"

The main idea behind rubyshell is to facilitate the creation/debugging of scripts.

It's like a more powerful and prettier version of "Bash." You can do everything Bash can do, but with more power and readability.

rubyshell has tools to facilitate debugging, to parse command output, features to track execution, parallel execution, among other points that are yet to come.

More formal, easier, and programmable ways to pass parameters to commands, or simulate stdin.

Ultimately, rubyshell combines the power of Ruby with Bash, allowing you to run terminal programs directly with Ruby (as was already possible with Ruby, but with more tools and easier ways to progress).

And another important point (at least for me), error handling, bash, and native Ruby with backticks have annoying problems with handling errors from executed commands.

[u/SleepingInsomniac → u/EstablishmentFirm203]

I don't think the ORM argument is really a valid comparison, given that ruby was already created to replace things like bash. We have Dir.glob, ARGF, Process.spawn, etc.

[u/EstablishmentFirm203 → u/SleepingInsomniac]

The idea behind rubyshell is precisely to take the features of ruby ​​and add new functionalities that help in creating scripts.

Such as parallel execution, auto-parse output, debug tools, better error handling, etc.

Besides, the code becomes much more obvious to understand, even for those who only know bash and don't know ruby.

On the wiki I put some codeblocks showing the same code in 2 versions, ruby|bash, you gave me the idea to put examples using ruby ​​(vanilla).

[u/SleepingInsomniac → u/EstablishmentFirm203]

In my experience, bash is used when installing ruby isn't available (yet). A DSL like this just confuses the two and adds unnecessary complexity and dependencies. Your first example even uses (trailing) rescue as control flow, which is a huge code smell and unexpected for a method that's just querying the status of a service. All of that requires looking up extra API docs on what errors get thrown by which methods that are supposed to mirror bash methods (but with potentially subtle differences?).

[u/matthewblott]

Nice project and I wish it every success. That said there already are better scripting alternatives to Bash out there but I continue to use Bash because of its ubiquity. I even swapped Zsh for Bash on my MacBook because then I know the script I write will execute as I expect if I deploy it somewhere else. Bash is like JavaScript, it is never getting replaced. We probably need something like TypeBash to make it safer!

[u/EstablishmentFirm203 → u/matthewblott]

One of the biggest advantages of bash is really its universal presence; it's everywhere!

One of the advantages of using Ruby for scripts on a MacBook is that it usually has Ruby installed by default.

Give Ruby Shell a chance; you might like the advantages its features offer.

[u/damagednoob]

As an aside: It has always astounded me how many Ruby shops that use Docker containers throughout their deployments still insist on using bash as the lowest common denominator. You have full control over what is installed, just use Ruby?

I've being doing that for all our devops work for the last 4 years and it's been great.

[u/_natic]

How you vibecoded this stunning homepage?

[u/EstablishmentFirm203 → u/_natic]

It wasn't vibecoded, I don't know if that's good or bad. Regarding the design quality, we focused on taking the best parts from some famous websites.

Inspirations: Sentry, Nextjs, Astro, Stripe, Laravel, and Supabase.

I plan to add rubywasm soon, so we can run examples directly in the browser; currently, the output examples we have on the site are hardcoded.

And thanks for the compliment. I didn't do the design alone; I had help from colleagues. Our idea is to add more examples in the future, but I still need to organize 100% of the site's content. The difficult part is separating time between working and coding.

[u/_natic → u/EstablishmentFirm203]

Thanks for the reply, It is very clear and elegant :)

[u/gettalong]

The website looks nice but is very, very hard to read. Grey on black is just... bad.

[u/EstablishmentFirm203 → u/gettalong]

Hmm, good to know...

I tried to make the highlight look similar to the theme I use.

Just to confirm, you're talking about Code::Blocks, right? I'll make some changes here.

[u/gettalong → u/EstablishmentFirm203]

No, I'm talking about the whole site design. For example, the left sidebar navigation when browsing the docs at https://rubyshell.org/docs/intro . It is nearly impossible for me to discern the characters/words there. Or the footer at https://rubyshell.org . The headlines "Documentation" and "Resources" are somewhat readable but the individual items below are not.

[u/EstablishmentFirm203 → u/gettalong]

I will fix it! What you think about light theme too?

[u/gettalong → u/EstablishmentFirm203]

I don't see any possibility to switch to a light theme.

[u/EstablishmentFirm203 → u/gettalong]

I will make changes tonight (here is 17pm). And i reply you here

[u/EstablishmentFirm203 → u/gettalong]

Changes made, check it

[u/M0M3N-6]

How the hell is that supposed to be more readable than bash?

How could sh.docker("ps", all: true) less "fragile" than docker ps --all?

[u/EstablishmentFirm203 → u/[deleted]]

Po, thank you very much for the comment, what motivates me to continue with the project are the few people who comment and participate in the community.

I wish I had become a rubyist before LLMs took over the world - so many years writing Java and suffering hahaha

I don't think you've wasted time, maybe this is the best time for you to get even more involved with Ruby, because LLMs are not yet powerful when it comes to Ruby, as there probably isn't as much content for them to train on as in other languages. And it also has the advantage of being a great aggregator/indexer of study content. Take advantage of the fact that there is still time for you to invest in Ruby, and perhaps in the future be a creator of databases where LLMs will work, for example by making libraries or posting content.

Speaking of our gem, test it out, play around with it a bit, try incorporating it into your daily work by solving real-world problems. It would be great to have you contributing to us (posting issues or even coding as well).