3 ms·

> 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

> 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 :)

t-3 5y ago
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.
- kaba0 5y ago
  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…
- throwawaygh 5y ago
  > 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".
jandrese 5y ago
> 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. The defaults are everything.
- throwawaygh 5y ago
  >> 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.

t-3 5y ago

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.

kaba0 5y ago
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…
throwawaygh 5y ago
> 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".

jandrese 5y ago

> 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. The defaults are everything.

throwawaygh 5y ago
>> 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.