I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.
I have yet to find a proper replacement for bash. Especially for scripts.
The two most common alternatives are 1) using some of the newer shells people have created, like Oil shell [0], or 2) using programming language like Python, JavaScript, or PHP.
The problem with using a newer shell is that you'll have to install the new shell anywhere you want to use the script. Meanwhile bash is ubiquitous. Unless you're the only one maintaining the script, you're requiring others to learn the other shell to maintain the script.
The problem with using another programming language is that they rarely have good ergonomics for doing what bash does: stringing together commands, command input, command output, and files. If you try to do that in another programming language, things suddenly get a lot more complicate or at least more verbose.
So I still use bash, but I recognize that it's strength is in running other commands and dealing with I/O. If I'm doing complicated logic that doesn't involve that, then I'll offload my work to another language. Sometimes that just means calling a python script from bash, not avoiding bash completely.
If people found that they work better by taking other approaches, the please share them.
I'll still write bash, but only if it's very trivial (~ <= 10-ish lines, no super-complex conditionals, etc). For anything else, it's worth stepping up to just about any more-robust language. If you don't like the hoops that something like Python makes you go through for basic shell-like operations, maybe try Perl? For middling-complexity scripts, perl can be a nice win over bash, without all the development overhead of Python. Perl5 is pretty much installed everywhere and universally compatible for anything but the very latest language features.
I usually resort to running inline scripts using python3 or node (using only the standard library) if I need to do something that I can't express in bash easily. That means avoiding stuff that have to look up and I won't remember or be able to debug in a month.
I like the idea of running inline scripts. This means that all the logic is in a single file so you don't have multiple files to copy around (e.g. a .sh file and a .py file).
I've done this with awk and jq, but haven't done it with node or python. But why not? It sounds like a good approach for some cases.
I love bash for anything that doesn't need to scale. The reason is reliability. I can't tell you how many times I've run into problems with python or similar on small library implementations. If I need to make an http request in my code and I'm using curl in bash and something fails, I can pretty much guarantee the problem is not curl itself. It's battle tested and deterministic. However the python script that forgets to wrap a try catch or configure proper tls auth or some other quirk? I have had those eat hours/days of my time and having to resort to tcpdump to sort out what's really happening. Same with SQL libraries/ORM vs SQL cli, same with Json/xml parsing libraries vs jq etc.
> The problem with using another programming language is that they rarely have good ergonomics for doing what bash does: stringing together commands, command input, command output, and files. If you try to do that in another programming language, things suddenly get a lot more complicate or at least more verbose.
tclsh is one way around that. Use a real first-class programming language, but in a mode where calling programs is as easy as it is in shell.
I think this is a valid point. bash is an overly complicated tool...so I'll write another tool on top of that (with none of the decades of debugging that bash itself has undergone) to make bash...LESS complex?
The problem is with bash itself.
We tend to undervalue ease of use and overvalue "cleverness."
Case in point: git. Very clever tool. Ease of use: terrible. But Linus wrote it and Linus is clever, so it must be us that's the problem.
We get what we value. Let's value ease of use more.
Yes. While I’m a huge fan of shellcheck and am one who actually have used and know bash deeply. No amount of linters or other tooling on top of bash can fix it.
Best solution is to just stay away.
For real. Just stop. Don’t try to be macho. The whole model of the language is fundamentally broken. I mean, stringly typed, global mode switches, one-character flags for fundamental comparison operators, defaulting to ignoring errors at every corner you look, functions especially. Each such idiosyncrasy on its own is enough to dismiss such a language, bash has them all plus more.
It has idiosyncracies because it's not a general purpose language. Even the things that she mentions are happening for good reasons - like the fact that set -x would break the expected behavior of || and &&.
Actually what language does crash when a function returns false? I mean some throw exceptions but isn't "false" a valid thing to return?
I find the same thing with makefiles - people don't understand what they're doing and expect them to work in a certain way because they haven't ever thought about build systems very deeply. Recursive assignment in Make catches almost everyone out e.g.
FLAGS=-b
COMPILE=compile $(FLAGS)
$(info compile command=$(COMPILE))
FLAGS=-a
myfile:
echo $(COMPILE) $? -o $@
outputs:
t43562@rhodes:~ make -f t.mk
compile command=compile -b
echo compile -a -o myfile
compile -a -o myfile
Despite this, making all assignments immediate to match other programming languages would take a VERY useful tool away. The more you understand these tools the more you know where to bother using them and how much effort to put into it.
That's easier said than done, and completely getting rid of bash may often not be worth the time and effort. But in general I agree, anything remotely complex I try to offload into scripts written in less idiosyncratic languages. Having some tools to help avoiding mistakes with the last 5% that stay bash scripts is super helpful in that case.
a part of me agrees with the aim of what you say: why not start afresh with something that is less prone to accidents? and i do agree with that idea. but i think it is also somewhat impractical to ignore that pretty much every server i've ever interacted with has a default, vanilla, bash installed, and if i know how to use that, it helps me get by.
not to say we can't and shouldn't try to do better.
