5 ms·

Just write scripts in Ruby

hackbinary 5y ago
Or Python, or tcl, or (eeek) Perl, or JavaScript. Or anything that can handle integers and floating point calculations natively.
- aaaaaaaaaaab 5y ago
  Bash handles integers natively.
- forinti 5y ago
  It doesn't really make sense to be squirmish about Perl in a discussion about bash.
nanomonkey 5y ago
Babashka for Clojure is my new favorite scripting language.
- agumonkey 5y ago
  Seriously impressive
jrochkind1 5y ago
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?
- CSSer 5y ago
  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.
  - bombcar 5y ago
    The only “danger” to bash is if zsh completely overtakes it - and even then scripts will probably be written in bash-compatible zsh.
  - dorianmariefr 5y ago
    bash is no longer the default shell on macOS
- ziml77 5y ago
  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.
aaaaaaaaaaab 5y ago
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 :)
chasil 5y ago
As soon as you get Ruby into busybox, I will be your biggest fan. I am not holding my breath.

Or Python, or tcl, or (eeek) Perl, or JavaScript. Or anything that can handle integers and floating point calculations natively.

aaaaaaaaaaab 5y ago
Bash handles integers natively.
forinti 5y ago
It doesn't really make sense to be squirmish about Perl in a discussion about bash.

nanomonkey 5y ago

Babashka for Clojure is my new favorite scripting language.

agumonkey 5y ago
Seriously impressive

jrochkind1 5y ago

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?

CSSer 5y ago
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.
- bombcar 5y ago
  The only “danger” to bash is if zsh completely overtakes it - and even then scripts will probably be written in bash-compatible zsh.
- dorianmariefr 5y ago
  bash is no longer the default shell on macOS
ziml77 5y ago
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.

aaaaaaaaaaab 5y ago

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

chasil 5y ago

As soon as you get Ruby into busybox, I will be your biggest fan. I am not holding my breath.