Every time I write a shell script that grows to more than about 20 lines I curse myself for not having written it in Python. The longer I have waited before throwing it away and redoing it, the more I curse.
This article says nothing to change my mind. I could build logging and stack traces in Bash. I admire the author's ingenuity. But again, why?
For example, anything to do with json can be done in 1 line of readable jq, while it could be 1, 5, or 20 lines in python depending on the problem.
I'd just like to put that out there because half of the time, the >n metric does not work for me at all. My shell scripts range from ~5-150 lines while python are 100+
My personal decision matrix for when to switch to Python usually involves the relative comfort of the rest of my team in both languages, the likelihood that future maintenance or development of the script will be necessary, and whether or not I’m dealing with inputs may change (e.g. API responses, since sadly versioning isn’t always a guarantee).
I don't agree that there exists such a thing as "readable jq" to start with. It's very arcane and difficult to follow unless you live and breathe the thing (which I don't). Furthermore, jq may or may not be present on the system, whereas the json package is always there in Python. Finally, I don't think having more lines is bad. The question is, what do you get for the extra lines? Python might have 5 lines where bash has 1, but those 5 lines will be far easier to read and understand in the future. That's a very worthwhile trade-off in my opinion.
I used to think this before I actually read how it worked. If you know shell, jq is extremely easy to pick up. It acts the exact same way, but pipes JSON entities instead of bytes ("text") like shell does.
Like the Unix philosophy, every filter does exactly one thing very well. Like shell, you write it incrementally, one filter at a time.
Genuinely, I do not blame you for thinking it's complex. I have never seen a concise, correct explanation of how jq works that builds an intuitive understanding. I have a near-complete one, and it's on my todo list to eventually publish it.
Anyway, I don't mean to say more lines is always worse, but that it is worse about half the time. Python is certainly more readable, but I'd rather spend 60 seconds making a long pipeline than 10 minutes making it work in python.
Want to count lines in a file? wc -l. Compress a directory? tar -zcf. Send that compressed file somewhere? Pipe it to ssh. Each of those is an ordeal in python and it's around 10 keystrokes in shell.
That being said, as a guy who does not have big prominent OSS tools under his belt, I am slowly but surely migrating away from shell scripts and changing them to short Golang programs. Already saved my sanity a few times.
Nothing against the first cohort of people who had to make computers work; they are heroes. But at one point the old things only impede and slow everyone else and it's time to move on.
I'm sorry Junegunn! I would never dream of stealing that kind of valor. I'll remember to flag [1] as a tutorial I wrote explicitly in the future.
Thanks for the clarification.
Thanks for fzf, by the way. Always one of the first things I install in a new environment.
I'm sorry Junegunn! I would never dream of stealing that kind of valor. I'll remember to flag [1] as a tutorial I wrote explicitly in the future.
ls | where size > 10mb | sort-by modifiedThis. Bash gives you all the tools to dig a hole and none to climb out. It's quick and easy to copy commands from your terminal to a file, and it beats not saving them at all.
Support for digging: once you have a shell script, adding one more line conditioned on some env var is more pragmatic than rewriting the script in another language. Apply mathematical induction to grow the script to 1000 lines. Split into multiple files when one becomes too large and repeat.
Missing support for climbing out: janky functions, no modules, user types, or tests; no debugger and no standard library. I've successfully refactored messy python code in the past, but with bash I've had no idea where to even start.
There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?
There were some languages shown in HN that compile to sh/bash (like oilshell[0]). I would think that's also a viable vector of attack but not sure how viable it actually is i.e. maintainers might have moved on for various reasons.
Ish. You can source whatever files you want, so if you split up your functions into logical directories / files, you can get modules (-ish).
> no tests
BATS [0].
[0]: https://github.com/bats-core/bats-core
> I've successfully refactored messy python code in the past, but with bash I've had no idea where to even start.
I say this with all kindness: you probably need to know more bash before you can safely refactor it. It is a very pointy and unforgiving language.
(a) instead of writing a shell script to operate a shell-operated tool, write a python script with a bunch of os.system('shell out') commands.
(b) instead of just invoking ffmpeg to do the things you want done, install an ffmpeg development library, and call the functions that ffmpeg itself calls to do those things.
What would be the argument for either of those?
I can’t even tell how many times I’ve seen multi-line Python scripts which could instead have been a shell one-liner. Shorter and faster.
I have also written shell scripts with hundreds of lines, used by thousands of people, which work just fine and would be more complicated and slower in other languages.
I firmly disagree with the all too pervasive blanket statement of “there are better languages”. It depends. It always does.
Yes it's a tradeoff. Every line of code is a liability. Powershell or python are probably "slower" which in my use case is negligible and almost never relevant. On the other hand, I can't help but view the often esoteric and obscurely clever bash mechanisms as debt.
For example, let’s take a file as input, filter for every "mypattern" line, then output them sorted.
Python example:
import sys
print(*sorted(line for line in open(sys.argv[1]) if 'mypattern' in line), sep='')
grep 'mypattern' "${1}" | sort
If you have a standard-ish environment, you'll have an array of Unix tools to compose together, which is what a shell is best at. Even a minimal image like busybox will have enough to do serious work. Golfing in shell can be a pipeline of tools: lately "curl | jq | awk" does a lot of lifting for me in a one-liner.
As soon as you say "switch to (favorite decent scripting environment)", you're committing to (a) many megs of its base install, (b) its package management system, (c) whatever domain packages you need for $work, and (d) all the attendant dependency hells that brings along. Golfing in a scripting environment is composing a bunch of builtin operations.
> As soon as you say "switch to (favorite decent scripting environment)", you're committing to (a) many megs of its base install, (b) its package management system, (c) whatever domain packages you need for $work, and (d) all the attendant dependency hells that brings along.
OK, but isn't jq just an example of a favorite scripting environment with a multi-meg install and a dependency system? What are you doing that's different from what you're advising everyone else not to do?
> Golfing in a scripting environment is composing a bunch of builtin operations.
Neither curl nor jq is a builtin operation.
No? jq is a single binary a little over half a MB with no runtime dependencies. You can simply download it and use it. And you only need that if it’s not already included in whatever system you’re using, which it likely is. It even comes with macOS these days, which is more than what you can say for Python.
https://news.ycombinator.com/item?id=44408432
> Neither curl nor jq is a builtin operation.
Pretty sure they meant it as in builtin with the system, not the language. As per their first paragraph:
> Even a minimal image like busybox will have enough to do serious work.
I just downloaded it to see what size it was, and it's 2200 KB.
> Pretty sure they meant it as in builtin with the system, not the language. As per their first paragraph:
>> Even a minimal image like busybox will have enough to do serious work.
Busybox doesn't include curl or jq. They aren't builtins by any standard.
This becomes obvious every time you set up a new machine and try to curl something, and then realize you have to install curl.
We both saw different versions. You looked at the Linux one, but I looked at the macOS one. The version which ships with macOS is smaller than the one on the website, but even so the website version is under one MB.
I’m intrigued by what causes the large difference.
> Busybox doesn't include curl or jq.
Thank you for the correction. In that case I don’t know what the other user meant. Perhaps they’ll come back and can clarify.
ls *.txt | { while read FILENAME; do <something> to $FILENAME; done; }
and so on. Once you know, you can get a lot done on e.g. a docker image, without having to install lots of other things first.
Agreed WRT shellcheck.
This is most common in Debian and Ubuntu, where ash is /bin/sh, and /bin/bash does not run in POSIX mode by default.
Some behavior of legacy bash of the '80s, prior to POSIX.2, can be surprising.
For actually _testing_ the scripts or its functions, I recommend ShellSpec
What? If globals are set outside the scripts, -u still works. If the author means they may or may not be defined outside the script, the ${VAR:-} construct allows it to expand to nothing if unset (just throw VAR=${VAR:-} at the top if you don't want to edit the body)
Also, I do not like the function return based on error code:
function ... {
...
(( check_level >= current_level ))
}
return $(( check_level < current_level ))That's throwing the baby out with the bathwater. Instead, default the optional global variables with something like:
"${GLOBAL_VAR:-}"
%(fmt)T -output the date-time string resulting from using FMT as a format string for strftime(3)
%(datefmt)T causes printf to output the date-time string resulting from using datefmt as a format string for strftime(3). The corresponding argument is an integer
representing the number of seconds since the epoch. Two special argument values may be used: -1 represents the current time, and -2 represents the time
the shell was invoked. If no argument is specified, conversion behaves as if -1 had been given. This is an exception to the usual printf behavior.
timestamp=$(date +'%y.%m.%d %H:%M:%S') printf -v timestamp '%(%y.%m.%d %H:%M:%S)T' -1I suppose what is really tripping people up is that bash can show up on all kinds of runtimes, some of which have the external tools one might need (jq, logger, etc) and some of which don't. So then you go searching for a minimum standard that can be expected to be present. Maybe POSIX or gnu coreutils. Reminds me of the shell horrors of the late 1990s where every script had to figure out if sh was really ksh and what variant of UNIX it was running on, and therefore what commands and options were available. I swear this was one of the great things about Perl when it came along, it just worked.
In 2025, I kind of see the attraction of single binaries like Go does. Ship the binary and be done. It is very un-UNIX I suppose (not so much golfing as having the beer cart drive you to the hole) but then again its not 1985 any more.
#!/bin/bash
die() {
local frame=0
while caller $frame; do
((++frame));
done
echo "$*"
exit 1
}
f1() { die "*** an error occured ***"; }
f2() { f1; }
f3() { f2; }
f3
Output
12 f1 ./callertest.sh
13 f2 ./callertest.sh
14 f3 ./callertest.sh
16 main ./callertest.sh
*** an error occured ***
[1] https://www.reddit.com/r/commandline/comments/g1vsxk/the_fir...
t43562•6mo ago
I use -e sometimes but I really dislike scripts that rely on it for all error handling instead of handling errors and logging them.
https://www.shellcheck.net/
^^ this tool has proven very useful for avoiding some of the most silly mistakes and making my scripts better. If you're maintaining scripts with other people then it is a great way of getting people to fix things without directly criticising them.
oneshtein•6mo ago