3 ms·
In defense of bash, in spite of its many footguns... you do yourself a disservice if you refuse to learn bash, which is rock-solid stable and has basically ubiq
by ryandv 2y ago
In defense of bash, in spite of its many footguns... you do yourself a disservice if you refuse to learn bash, which is rock-solid stable and has basically ubiquitous deployment. SSH into any server or use any UNIX-like environment and you are instantly at home. While JS and Ruby ecosystems churn every year and mandate yet another round of dependency hell and keeping up with the latest and greatest in rubocop bikeshedding, bash just keeps on ticking throughout the years with little to no recurring maintenance burden.
That being said, if you are doing something other than just piping together processes and managing unstructured streams of flat plaintext, bash is the wrong tool for the job. bash is best used interactively, in the REPL, for having a back-and-forth conversation with the machine and interrogating its current state (filesystem, resource usage...), or that of other machines over the network (that is, using dig, curl, openssl, ping, mtr, etc), and processing streams of text. Even for lightly structured data, like if I am doing boring, garbage CRUDdy tedium on the web and need to figure out how to do some rudimentary transform of a JSON document, figure out which headers to send and which endpoints to hit, curl and jq it is - and there I am, reshaping the data in as interactive of an environment it gets.
The minute I need to write something for a non-interactive, end-user use case, with requirements for better domain modelling / structuring of data, testing, deployment, readability, maintainability, extensibility, etc. it is time to reach for a more modern language. But if you want to talk to the machine, virtually any (non-Windows) machine, interactively, bash is your lingua franca, or perhaps your Latin/Ancient Greek/Aramaic, esoteric and outdated as it is.
I also get the feeling that people just recoil at any level of complexity and need to hide behind their clean, simple abstractions these days. As a Haskell enthusiast, I am also susceptible to this tendency, but one needs to be at least capable of diving into the historical, messy work underneath the hood.
- chasil 2y agoThe lingua franca is actually the POSIX shell: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... There is a bunch of bash that you should not learn. The differing coprocess syntax from korn is one particular bugbear. Still, if you are hacking on ReaR or other critical tools that sink deep into bash's slang, you don't have much choice.
- kfajdsl 2y agoI mean, yes, but 99% of deployments are going to be bash on some flavor of Linux.
- chasil 2y agoNo, they are not. The Debian/Ubuntu family uses the "Debian Almquist Shell" (dash) as the system shell (#!/bin/sh) for a number of reasons. It is very much not compatible with anything fancy from bash (or korn). The bash shell is available as #!/bin/bash, but that opens the door to a new set of problems (in that POSIX mode is not enabled). In the embedded realm, busybox also implements the Almquist shell, but it does throw simple bash "slang" back in (but not this does not include arrays).
- denkmoon 2y agoHow often don't you have bash on a debian/ubuntu system though? #!/bin/bash and away you go. Every workplace I've been that uses debian just goes for bash in the shebang.
- chasil 2y agoWell, there are a few things you should consider. OpenWRT is undoubtedly using busybox. I actually saw the busybox copyright on a point-of-sale terminal at Old Navy a few years ago. The embedded realm is vast, and bash is too big for it, or intolerable because of gplv3. Android uses mksh as the system shell. The more that you know of the korn dialects, the more comfortable you will be in scripting on Android. There is no native bash, as Android's userland is BSD. That realm is also vast. Finally, Debian/Ubuntu does give you /bin/bash, but if you don't understand the need for "set -o posix" then the scripts that you wrote for CentOS will fail in many interesting ways, because you are carrying the baggage of bash's first decade, before the POSIX shell standard. So yes, cutting your scripting away to pure POSIX.2 has considerable worth. It runs everywhere.