Earlier quoted context omitted.
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?
See https://metacpan.org/pod/pp for one tool to do that.
Ruby: A great language for shell scripts
281–290 of 368 posts
Re: Ruby: A great language for shell scripts
#282No it’s not a great language. Too many ways to do the same thing. Not packaged by default on most Linux. Monkey patching makes things even harder to debug.
You're the one doing monkey patching when you're writing a program. Don't do it if you think it makes things hard.
Re: Ruby: A great language for shell scripts
#283Earlier quoted context omitted.
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?
I'm currently working with 150MB worth of gzipped JSON - marshalling the full file from JSON to ruby hash eats up a lot of memory. One tweak that allows for easier lazy iteration over the file (while keeping temporary disk Io reasonable) is to pipe it through zcat, jq in stream mode to convert to ndjson, gzip again - for a temp file that ruby zlib can wrap for a stream convenient for lazy iteration per read_line...).
Generally marshalling a gig or more of JSON (non-lazily) takes a lot of resources in ruby.
Re: Ruby: A great language for shell scripts
#284Earlier quoted context omitted.
Hearing people still mention "monkey patching" always makes me chuckle... I haven't "monkey patched" anything in Ruby in > 5 years, and I don't see it in any of the popular libraries/gems anymore either.
Especially when the big difference is that Ruby had proper OO system that allowed patching, when necessary, to be done in much saner way... whereas the origin of monkey patching seems to by Python with its totally broken magical method names and kitbashed object model.
Module#prepend was introduced in Ruby 2.0, in 2013, which was the solution to monkey patching.
Re: Ruby: A great language for shell scripts
#285Earlier quoted context omitted.
Especially when the big difference is that Ruby had proper OO system that allowed patching, when necessary, to be done in much saner way... whereas the origin of monkey patching seems to by Python with its totally broken magical method names and kitbashed object model.
Module#prepend was introduced in Ruby 2.0, in 2013, which was the solution to monkey patching.
Well, that and Module#refine.
Re: Ruby: A great language for shell scripts
#286Earlier quoted context omitted.
Instability. Ruby has not been the same language for very long. Migrating to 1.9 was a huge hassle for many firms. This may seem like a long time ago in tech years; but then there was Ruby 2.0; and shell scripts, meanwhile, have stayed the same the whole time. A secondary reason is that Ruby has been very slow for much of its life, which means that for situations where you need to run a huge stack of scripts -- init…
Mentioning 1.9 migration and ruby being slow? Python 2 to 3 was waaaaay worse and more negatively impactful, and equally slow (slower in most cases). Ruby never had US market penetrative as perl or python, which were basically invented in the US, and congregated people from the academic realm. These things aren't decided based on meritocracy (no things ever are).
> Mentioning 1.9 migration and ruby being slow? Python 2 to 3 was waaaaay worse and more negatively impactful
Python 2-to-3 was mainly worse than Ruby 1.8 to 1.9 because Python had already won, and had a much bigger and more diverse ecosystem.
Re: Ruby: A great language for shell scripts
#287Earlier quoted context omitted.
Instability. Ruby has not been the same language for very long. Migrating to 1.9 was a huge hassle for many firms. This may seem like a long time ago in tech years; but then there was Ruby 2.0; and shell scripts, meanwhile, have stayed the same the whole time. A secondary reason is that Ruby has been very slow for much of its life, which means that for situations where you need to run a huge stack of scripts -- init…
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.
[deleted]
Re: Ruby: A great language for shell scripts
#288Earlier quoted context omitted.
This complaint comes up enough that I'm surprised nobody's created the Ruby equivalent of GraalVM, to compile a Ruby script, all its deps, and a WPOed subset of the Ruby runtime, into a native executable.
It's not quite what you're describing, but TruffleRuby is Ruby on GraalVM: https://github.com/oracle/truffleruby Unlike GraalVM Java, as far as I can tell TruffleRuby doesn't provide a bundler that can create a single executable out of everything, but in principle I don't see why it couldn't.
Worth noting that the GraalPython implementation does support creating a single binary.
https://www.graalvm.org/latest/reference-manual/python/stand...
I'm not sure I'd try replacing shell scripts with natively compiled Python binaries. That said, I use a Kotlin Scripting based bash replacement in my own work that has many useful features for shell scripting and is generally much more pleasant. You have to "install" it in the sense of having it extracted somewhere, but it runs on Win/Mac/Linux and can be used without root etc.
Re: Ruby: A great language for shell scripts
#289Earlier quoted context omitted.
> I sometimes wonder why we don't see ruby used for shell stuff more often. The reason we don't see Ruby used more for shell stuff is because Python won this particular war. It's already installed on basically every Linux distribution out there, and this simple fact outweighs all other language considerations for probably >95% of people who are writing shell scripts in something that isn't Bash. Personally, I don't m…
Yes, Python won the war, which is a pity. Linux distributions started getting bloated at the same time they switched to Python for everything. Yum hanging inexplicably and such things never occurred before. The BSDs do not have this problem (yet!). I hope they stay sane and keep using Perl/sh.
Yum hangs not because of Python but because Fedora's RPM metadata is bloated compared to other distros so yum has to load and process much more data.
Re: Ruby: A great language for shell scripts
#290Earlier quoted context omitted.
I think golang is used because you can easily create a single static binary, which is incredibly easy to distribute. I often find non-trivial CLI tools written in Python cumbersome because of the dependency wrangling necessary.
Most shell-ish scripts probably use no dependencies and will not be picky about exact version
That's not my experience at all. Shell is often glue between different utilities and unless it's being run in a controlled environment like a docker container, you have no idea what's on the base machine.