Live data from Hacker News

Ruby: A great language for shell scripts

lucasoshiro.github.io

271–280 of 368 posts

Re: Ruby: A great language for shell scripts

#271

It seems like a waste of precious syntax to dedicate backticks to running shell commands. What's between the backticks is not even portable; the commands rely on an operating-system-specific command interpreter. > puts `ls`.lines.map { |name| name.strip.length } # prints the lengths of the filenames Fantastic example, except for the commandment violation: "thou shalt not parse the output of 'ls'"! You really want to…

And what psychopath is trying to parse the output of ls?

None of this makes any sense to me, and I write Ruby for my day job.

Re: Ruby: A great language for shell scripts

#272

Earlier quoted context omitted.

Pex was also the solution I landed on after evaluating several non-container options for distributing a Python project to arbitrary Linux hosts. It works well but with one huge caveat: although you bring the stuff required to reconstitute the venv with you, you’re actually still using the system’s python executable and stdlib!! So for example if you want to make a project targeting all supported Ubuntu LTS versions,…

I wish an easy cross-platform PEX or shiv [1] were a thing. Binary dependencies are the biggest reason I prefer the new inline script metadata spec ( https://packaging.python.org/en/latest/specifications/inline... ) and `pipx run`. Luckily, they're pretty great. They have changed how I write Python scripts. The way inline script metadata works is that your script declares arbitrary dependencies in a structured top co…

All else being equal I’d probably prefer poetry for the broader project structure, but that would definitely be compelling single script use cases.

Re: Ruby: A great language for shell scripts

#273
post #172

Earlier quoted context omitted.

Ruby is surprisingly picky with white space

Can you give an example? I can't think of a single situation where whitespace matters in Ruby (unless of course you forget to put a space between two commands or something silly).

It's not really a problem in practice (and I love Ruby), but it's still wild to me that they made the parser do this:

    $ irb
    irb(main):001:0> def foo(x=70) = x
    => :foo
    irb(main):002:0> i = 2
    => 2
    irb(main):003:0> foo / 5/i
    => 7
    irb(main):004:0> foo /5/i
    => /5/i

Re: Ruby: A great language for shell scripts

#274

Earlier quoted context omitted.

Perl is deeply underappreciated and needs a lot more love. One of the keynotes at the polyglot conference that I run is going to be Perl talk and I'm really looking forward to it.

Does it still require global library / module installations for your script's dependencies? If so, hard pass.

It does not, and has not for at least a decade!

Re: Ruby: A great language for shell scripts

#275

Earlier quoted context omitted.

Your first two points don’t seem valid, in my experience. The Ruby 2.0 migration wasn’t that interesting from a compatibility perspective; it certainly wasn’t anything like Python 2 -> 3. And Ruby is __not__ slow compared to bash. I don’t where these myths get started, but someone needs to justify the Ruby-is-slow thing with actual data.

> I don’t where these myths get started, but someone needs to justify the Ruby-is-slow thing with actual data. As an outside observer of the Ruby world, I have an impression that it was Ruby MRI that was slow. CPU-bound synthetic benchmarks like the much-criticized Benchmarks Game showed Ruby ≤ 1.8 a good deal slower than CPython 2. Here is an illustrative comment from that time: https://news.ycombinator.com/item?id=…

ruby 3.3.0 vs ruby 1.8.7

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Ruby: A great language for shell scripts

#276
post #141

Earlier quoted context omitted.

This is indeed why I use Perl over Ruby. As long as it's not for a Window machine, a Perl script is deployed by copying it over and that's it.

That's true of Python and Perl as long as you keep using only the features built in in the core language (standard lib or whatever they call it.) The same applies to Ruby. My scripting language is bash in at least 99% of cases. I used to program in Perl when I need some complex logic. I stopped using it some 10 or 15 years ago when I switched to Ruby for two reasons: I became more familiar with it than with Perl and…

> The same applies to Ruby.

With a big difference -- Perl and Python will always be installed on these machines, whereas Ruby might need two deployment steps: (1) copy file, (2) install Ruby!

Re: Ruby: A great language for shell scripts

#277
post #274

Earlier quoted context omitted.

Does it still require global library / module installations for your script's dependencies? If so, hard pass.

It does not, and has not for at least a decade!

So any guides on how to make a self-contained Perl script that needs dependencies?

Re: Ruby: A great language for shell scripts

#278

Earlier quoted context omitted.

I wish an easy cross-platform PEX or shiv [1] were a thing. Binary dependencies are the biggest reason I prefer the new inline script metadata spec ( https://packaging.python.org/en/latest/specifications/inline... ) and `pipx run`. Luckily, they're pretty great. They have changed how I write Python scripts. The way inline script metadata works is that your script declares arbitrary dependencies in a structured top co…

All else being equal I’d probably prefer poetry for the broader project structure, but that would definitely be compelling single script use cases.

You can also combine the two. Something I have done is script dependencies in inline script metadata and dev dependencies (Pyright and Ruff) managed by Poetry.

Re: Ruby: A great language for shell scripts

#279
post #225

Earlier quoted context omitted.

You can pipe with the `pipeline*` method of open3 which is part of the stdlib: For example: require "open3" last_stdout, wait_threads = Open3.pipeline_r("cat /etc/passwd", ["grep", "root"]) last_stdout.read # => "root:x:0:0::/root:/bin/bash\n" wait_threads.map(&:value).map(&:success?) # => [true, true] https://ruby-doc.org/3.2.2/stdlibs/open3/Open3.html

Can you easily chain these, though? (gzcat some.txt|grep foo|sort -u|head -10 etc?). Especially lazily, if the uncompressed stream is of modest size, like a couple of gigabytes?

I'd suspect you could do that with Open3, but if you are, why not just read the file and process with Ruby instead?
Post reply on HN