Just don’t forget to install the correct Ruby version, of course keeping the system’s Ruby intact, so better use RVM for that, and of course you shouldn’t install random gems globally, so better do the whole thing via Bundler, and of course don’t forget to check in the Gemfile.lock too.
Actually, you can expect a recent version of Python 3 from most distros these days. Stdlib is quite powerful and no hurt would come from a small number of globally installed libs with stable APIs, like click and requests.
The key word there is "these days". There have been a lot of computers built and software set up in the last ~20 years that are still getting used today and will be for a long time. Not every environment is using $latest.
Despite this you can expect your bash scripts written today to work on any of these machines and their ancient OS installs. This is primarily because people writing in Bash care enough to not use new features, not the lack of new features in Bash.
Python 3 (3.6) is available in the base repos for Ubuntu 18.04 and CentOS 7. Ubuntu 16.04 was EOLed in 2021-04 and CentOS 6 is EOL since 2020-12. Using anything older is plain insecure (unless you are paying for ESR contracts beyond the EOL date of the LTS). I am definitely not talking about "latest".
Canonical offers free Ubuntu Advantage for 3 machines which gives you extended service maintenance for even older distros like 14.04 (which is what I am using to type this). Ubuntu is a great distro because it supports each LTS for a full 10 years. Constantly upgrading and breaking things and having to switch software and workflows is way more insecure imo.
Additionally, there are tons of devices out there that will never get updated that run even older unsupported linux distros and do their job just fine. And modern written bash will run just fine there too.
> Just don’t forget to install the correct Ruby version
This justification for bash has always been perplexing to me. If I’m operating in an environment where my ONLY reliable infra invariant is “bash will probably work”, cleaning up the org’s infrastructure clusterfuck is probably my #1 priority.
(Or I guess in a few cases the fleet are not boxen but little embedded/iot devices, in which case you probably don't want to be running any of these sorts of scripts for a whole host of reasons...)
> of course you shouldn’t install random gems globally… Or you can just use bash and keep your sanity.
What are some scenarios where you’d need a gem in Ruby but Bash just works?
The only situations I can think of are cases where you’re using Bash to call out to some executable that does fancy things. Which (1) you can do from any scripting language anyways, and (2) means you’re just shifting dependency management from the package manager to the image/Dockerfile.
But actually, the combination of justifications here is particularly perplexing. If the org has a stable way of handling system images, then you'll know which version of $scripting_language should exist and where it's installed. The only way you end up with language version woes is if you don't have standardized infra. BUT... if you don't have standardized infra, and Bash can do things that Ruby can't without special Gems, then it stands to reason that you're in a situation where your Bash scripts depend on the magic state of individual unicorn boxes?! Which is particularly fragile and frightening and far worse than installing some local gems or whatever!
IDK. The purported benefits of Bash always sound like they flow out of environments where there are basically no fleet-wide infrastructure invariants.
"Just use $scripting_language" might be the best advice in this thread just as a sort of canary in the coalmine. I.e., if your org can't "Just use $scripting_language" because "which version?" then the team will probably benefit tremendously in an infinite variety of ways from an afternoon of infrastructure cleanup. Regardless of whether they use bash or a scripting language going forward :)
The advantages of bash are almost all related to it NOT being a "real" programming language. The terseness, ease of writing self-modifying code and anonymous functions, lack of typing, flexible syntax, easy interoperability with any other language and program through any available interface, are not really desirable for writing stable and maintainable code. They are hugely desirable for quickly hacking something together, testing and learning, and the numerous simple scripting tasks involved in system administration.
> They are hugely desirable for quickly hacking something together
Undeniably, yes. I was there in the 90s ;-)
But hacking things together in a way that's robust is difficult, and bash isn't a good match for that difficulty.
These days I mostly operate in the realm of "how can I enable others to hack things together without blowing tens of millions of our dollars and their very early career on a stupid mistake".
But it is so full of landmines that even those quick dirty hacks will fail.
Also, don’t even start me up on self-modifying code, we have one at a work project and it sometimes just fails and results in inserting the same echo statement at each run, resulting in every bootstrap displaying 2^n messages, depending on when have I last cleaned it up…
> This justification for bash has always been perplexing to me. If I’m operating in an environment where my ONLY reliable infra invariant is “bash will probably work”, cleaning up the org’s infrastructure clusterfuck is probably my #1 priority.
That is not your job. Your job is to get that machine working using whatever is already installed. Adding a new package means going to the production committee with your proposal and justification and analysis of the increased threat surface.
>> This justification for bash has always been perplexing to me. If I’m operating in an environment where my ONLY reliable infra invariant is “bash will probably work”, cleaning up the org’s infrastructure clusterfuck is probably my #1 priority.
> That is not your job.
This sort of thing is definitely your job have the word "Principal" in your job title, and probably also if the word "Senior is in there as well ;-)
And in any case everyone is responsible for excellence in the milieu in which their team operates. If Senior or even fresh grad Jr. comes to me with a solid good idea I'll champion for it as if it were my own baby. And then recommend/fight for rapid promotion in the case of Jr or put in a good word for promotions for the Sr.
If you recommend your org have standardized images with well-documented info about language versions etc. and the answer you get from your management/tech leadership is "not your job", I recommend finding a new job.
> Adding a new package means going to the production committee with your proposal and justification and analysis of the increased threat surface.
The context of my quote was "knowing which version of ruby/perl/python is installed". There's almost certainly a version of one of those on your standard linux machine, and everyone pushing to prod should damn well be able to look up exactly which one.
> Adding a new package
The general debate here goes way beyond adding a new package. Good infra needs WAY better invariants than "definitely bash is installed in the usual place". If a concern is "IDK which version of Ruby is installed on the machines I'm targeting" then either you're fighting fires and need to keep every intervention really damn simple or else your org as Real Issues. In either case, bash is the enemy.
> The defaults are everything.
Those defaults aren't handed down from Gods. Your org chooses them.
Installing ruby/predicting the version of ruby installed/writing ruby that can run on any version installed... is unfortunately non-trivial.
I think pretty much the only reason people write bash is because you have an incredibly high chance of bash being installed and a version of bash being installed that will run whatever bash you write just fine.
Perl is honestly almost as reliable to be there predictably and compatibly... but I guess people would rather write bash than Perl?
Is there any risk of Bash ever going away? It seems like it's the de facto shell. I remember considering whether or not I should learn Perl at one point. It didn't even feel like a choice with Bash. Trendy shells seem like they have no choice but to support it too.
I feel like what usually makes me reach for something beyond Bash is really a matter of wanting or needing some dependency that wasn't written in it for whatever reason. Usually this happens right at the point where the script/utility starts to turn into a library/program, so it's trivial to just transpose the control flow into whatever language is required at that point and go from there. This of course raises the type of concern you mentioned about Ruby, but at that point it's hopefully worth the trouble to address.
Bash might be consistent, but what about the programs you're calling out to? Even basic utilities have different options between BSD and GNU Coreutils. Something like git might not have options you're expecting due to differences between versions. Or if you need to download a file using HTTP, you will run into a problem when you run on a machine that has wget when your script was expecting cURL.
And yes, you have these sorts of problems with other languages, but my point here is that Bash doesn't free you from them.
