As a self proclaimed shell advocate I am… intrigued. As a self proclaimed shell advocate, I also have a revulsion to back ticks.
Yes, all hail $( )
I haven't used backticks in my shell scripts in years.
Ruby: A great language for shell scripts
91–100 of 368 posts
Re: Ruby: A great language for shell scripts
#92Hell yeah! I’ll never forget being fooled by HN that you have to use Perl if you want portable scripts that aren’t bash, writing a whole script with it, and having a coworker politely, yet firmly, tell me that I am dumb and it should just be Ruby… and it was a script I was checking into a Rails app! It’s even trivial to include dependencies with bundler inline https://bundler.io/guides/bundler_in_a_single_file_ruby_s…
this is… somewhat horrific, right? would anyone do this without explicit version pinning? loosely pinned deps installed on execution sounds fucking awful.
[deleted]
Re: Ruby: A great language for shell scripts
#93Hell yeah! I’ll never forget being fooled by HN that you have to use Perl if you want portable scripts that aren’t bash, writing a whole script with it, and having a coworker politely, yet firmly, tell me that I am dumb and it should just be Ruby… and it was a script I was checking into a Rails app! It’s even trivial to include dependencies with bundler inline https://bundler.io/guides/bundler_in_a_single_file_ruby_s…
this is… somewhat horrific, right? would anyone do this without explicit version pinning? loosely pinned deps installed on execution sounds fucking awful.
Well, don’t use this then. It’s a neat feature for quickly iterating, and you can quite easily go up from here to a proper Gemfile/Gemfile.lock.
Re: Ruby: A great language for shell scripts
#94Earlier quoted context omitted.
Ruby is unsuitable for large projects for the same reason python is, but it also lacks the huge ecosystem and labor pool that python has. When I'm interviewing and a company tells me ruby is the main language, I end the call.
“X is unsuitable for large projects” when there are many readily discovered existence proofs to the contrary (including but not limited to $1B+ businesses, massive communities, deep thoughtful and disciplined engineering spokespeople, etc.) strikes me as a common trope here on HN. (Which is not to say X is flawless even at scale or a clear best fit along all axes. That is true for no X that I know of.)
The fact that a language is used for large, successful businesses/projects doesn't mean another language wouldn't be better. It's just terribly difficult to measure such things.
Re: Ruby: A great language for shell scripts
#95Earlier 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.
> I often find non-trivial CLI tools written in Python cumbersome because of the dependency wrangling necessary. I'm thinking of trying out Mojo in large part because they say they're aiming for Python compatibility, and they produce single-file executables. Previous to that I was using PyInstaller but it was always a little fragile (I had to run the build script a couple of times before it would successfully complet…
You could try Nuitka [1], but I don't have enough experience with it to say if it's any less brittle than PyInstaller.
[1]: https://nuitka.net/
Re: Ruby: A great language for shell scripts
#96I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…
> ... maybe extract those files to required files, add gems, whatever.
CPAN is the killer feature of Perl. It just works. First off, most of the time I don't need a CPAN module for doing shell scripting in perl. Perl itself is rich enough with the file manipulations that are needed for any script of less than 100 lines.
My experiences with Ruby and installing gems have been less pleasant. Different implementations of Ruby. Gems that don't compile / work on certain architectures. Breaking changes going forward where a script that was written 2 years ago doesn't work anymore. Sometimes it's someone was doing something clever in the language that doesn't work anymore. Other times its some gem got updated and can't be used that way anymore. ... which brings us to ...
I believe that Go's advantages come into play when the program gets more complex that that 100 line size and it becomes a "program" rather than a "script" that has complexity to deal with. Furthermore, executables built in Go are most often statically linked which means that someone upgrading the libraries doesn't break what is already working.
Re: Ruby: A great language for shell scripts
#97Earlier quoted context omitted.
I assume it means Linux Standard Base: https://refspecs.linuxbase.org/LSB_3.2.0/LSB-Languages/LSB-L...
Thanks, I didn't know about that! I'm curious though; even LSB 5.0 only demands Python 2.4: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages... Do people really write scripts against Python 2 just so that they're guaranteed to be supported by LSB?
Nobody actually follows the LSB as written. But it remains useful as an idea of "stuff that was installed in old distros so usually has some newer version available".
Assuming you can survive all the incompatible interpreter changes for Python etc., the main annoyance with LSB proper is shared library versions.
Re: Ruby: A great language for shell scripts
#98Earlier quoted context omitted.
Mmm. I’d argue that all shell scripts use a ton of dependencies that are different across Unix/Linux. I. E. ‘sed -i’ is only in GNU sed. Same with ‘grep -P’.
This has bitten me many times
It’s why if my bash turns into more than a page or two I start re-evaluating it and turn it into python
Re: Ruby: A great language for shell scripts
#99Earlier quoted context omitted.
Many distros come with Ruby standard, it's not very big and I think it has a lot to recommend it over Python or Perl when it comes to lightweight scripting for sysadmins and day to day automation. I wouldn't necessarily pull it into an open source project where they weren't already present, but I would definitely choose it for personal use well before Python or Perl
Ubuntu, Debian, Arch, CentOS - none of these, as far as I know, ship with a Ruby interpreter by default. I’d like to be wrong, but I don’t think many do.
Does Arch even ship with Python by default? Its whole thing is being minimalist by default and letting you customize what is and is not installed.
Re: Ruby: A great language for shell scripts
#100I sometimes wonder why we don't see ruby used for shell stuff more often. It inherited most of the good stuff for shell scripting from Perl, and Perl took a lot of it's syntax from sh and sed and awk, so almost anything you can do in shell script you can do in ruby, but with an option of making it gradually less terse and more readable, while having sane variables and data handling from the start. Also ruby is great…
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.
Bootstrapping and different behavior for different versions and not being able to use the dependency ecosystem really make it a lot more difficult than people realize if you’re trying to “script” at scale.
I’ve used rust for this task but people get mad that I’m calling it a “script”. “That’s not a script that’s a program” which…sure. But so maybe we need another term for it? “Production-scripts” or something.
My experience is rewriting Ruby and bash buildpacks for the open spec CNCF Cloud Native Buildpack project (CNB) https://github.com/heroku/buildpacks
I agree that Ruby is easier to start and grow complexity, that would be a good place to start.