Of course, as I write this ansible is broken on one of my machines for reasons that appear to stem from a python 3.x->3.y update, so...
OTOH a script for /bin/sh written 30 years ago has a good chance running today unchanged.
Having said that, I still would not recommend shell for anything that needs to be robust and secure.
What was definitely problematic was the update from 2 to 3. Another problem may be dependency management (people not pinning dependencies). But the python itself? What does it even mean? Interpreter not starting?
Usually when I port shell scripts to python, I create a folder for it and throw in some setup.py / requirements.txt. But lately, I've automated most of the deb package creation process (https://copier.readthedocs.io), and I typically create the whole deb package. Of course, for single use stuff, I don't bother with either.
Unfortunately requiring approval and authentication from a random incorporated entity running a CA every 90 days is inherently complex. And all the ACME protocol implementations do is hide that inherent complexity by adding even more. CA TLS HTTP is very fragile but it could be made less so if corporate browsers didn't demand short lifetime certs-- a demand reasonable for businesses but not for human people or things expected to last longer than a few years without being touched.
All of this also excludes that the fact that your shell script will be just as janky in 10 years as it is now. Again, I regularly, regularly see shell scripts from companies that HN fawns over that don't pass shellcheck and have inherent issues that don't occur in better scripting languages, or full programming languages.
"Forward-compat" is not unique, and not a value proposition to me if it inherently means less reliable function.
Shell scripts can be and often are jank. But at least it's stable jank. Shell devs tend to write portable, stable code because that's the entire point of dealing with the shell jank.
> This wasn't a debian is old thing.
From my reading and understanding, yeah, it was.
If you're contradicting a person's argument ("yeah, it was") at least provide some more explanation, otherwise your comment is rarely more than a "is too!".
But shell is really not hard if people stick to a few easy guidelines:
- quote all var expansion, e.g., "$var" not $var or ${var} (very rare to need otherwise, and never for untrusted data)
- use "$@" to perfectly forward arguments (not $@, not $*, not "$*" except when you want to turn many arguments into one)
- don't use eval
- use `set -eu` and explicitly handle functions/commands that may benignly return/exit non-zero, e.g., `diff -U10 ./a ./b || true`
- use printf on untrusted strings instead of echo (just use it generally, I say), e.g., printf %s\\n "$var" instead of echo "$var". One of the few times you want to use "$*" is with printf though, e.g., printf %s\\n "$*" instead of echo "$@". Try them out, easy to see why, as with one thing to format and multiple arguments, `printf %s\\n "$@"` is equivalent to `for i in "$@" ; do printf %s\\n "$i" ; done`
- when using xargs, use -0 if available, or at least -d\\n if available (busybox doesn't have it for example). also usually want to use -r
Or just use a scripting language that eliminates many of these headaches (nushell) or a real programming language.
I get it, I really do. At least now I have nushell for some sanity, but I still find myself constantly writing a shell script and then realizing after a few iterations that I should've just written in nushell/Rust.
As a thought experiment, how many places rolled out acme.sh to prod and didn't bother code reviewing it or running it through shellcheck?
At least shell is good at a specific and very useful thing (sequences and pipelines of other commands), and is already installed on most machines -- even windows nowadays since almost everyone has git installed. My "build system" for C projects is just doing the following from pwsh: `& "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build.sh`
Most software is not great. That is the issue.
"bash is everywhere" is just more lipstick on the pig, in my strong opinion.
- The barrier to entry for shell scripting is tiny. You basically start with `ls` in an interactive shell and end up writing a frickin' 500-line monstrosity within a month.
- POSIX has fossilised scripting languages. I hoped we'd have something like PowerShell by now, but although we have some fine alternatives, none of them seem to be good enough to actually overcome the inertia of POSIX.
- Doing something that looks correct is easy, but doing the right thing is super effing hard. See looping through complex sets of files.
- People use statements like "It's just a script", as if scripts are somehow easy to write. Bullshit.
I was using shell because the project want to maintain compatibility between different distros (including some weird customized one without `ps` and `sed`), but that's all. Shell is not a good choice for things other than scripting.
Was it even run through shellcheck?!
Stop writing this stuff in shell people. 95% of the time I review any (posix, nushell lacks most of these issues) shell scripts, it's obvious they would fall apart the second any string unexpectedly had a space in it. Even scripts written by darling companies of HN.