4 ms·

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 insta

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. Or you can just use bash and keep your sanity.

throwawaygh 5y ago
> 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.
  - 5y ago
deleted 5y ago
[deleted]
smarx007 5y ago
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.
- superkuh 5y ago
  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.
  - smarx007 5y ago
    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".
    - superkuh 5y ago
      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.
      - smarx007 5y ago
        Wow, I learned something new today! Didn't know you could get such a subscription for free.
totony 5y ago
This is one of the reasons I think nix is a game changer. Not need to care about that, just put everything in nix-shell.

throwawaygh 5y ago

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

deleted 5y ago

[deleted]

smarx007 5y ago

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.

superkuh 5y ago
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.
- smarx007 5y ago
  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".
  - superkuh 5y ago
    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.
    - smarx007 5y ago
      Wow, I learned something new today! Didn't know you could get such a subscription for free.

totony 5y ago

This is one of the reasons I think nix is a game changer. Not need to care about that, just put everything in nix-shell.