There's a script on my work laptop that I wrote in 2014. It backs up a handful of config files, tars them, and drops the archive in a dated folder. Forty-three lines. No dependencies. I ran it this morning on a machine that didn't exist when I wrote it, on an operating system version that came out last year, and it worked without a single edit.
That's the thing about Bash that nobody puts on a slide deck.
The Shell Everyone Keeps Eulogizing
For the better part of a decade, I've watched the tech press announce Bash's cultural death with the enthusiasm of someone who just discovered a newer coffee shop. First it was Zsh — and fine, the autocomplete is genuinely lovely. Then Fish arrived with its friendly syntax highlighting and web-based configuration, which felt almost aggressively approachable. Now Nushell is the darling, treating shell output as structured data, which is a genuinely interesting idea. I've tried all of them. Some I've lived with for months.
I keep coming back.
The honest reason isn't stubbornness, though my wife might contest that. It's that Bash is the one shell I can trust to be there — on the remote Linux server, inside the Docker container, at the bottom of the embedded system, in the CI pipeline that some contractor set up three years ago. When I SSH into an unfamiliar machine at 11 p.m. because something is on fire, I am not thinking about my shell preferences. I am thinking in Bash, because Bash is what's there.
Ubiquity is underrated as a technical virtue.
What Portability Actually Costs You
I want to be fair to the alternatives, because the criticism of Bash is largely correct. The syntax is genuinely strange. Arrays are a late addition that still feel bolted on. String handling will surprise you in ways that feel almost personal. The quoting rules — the double quotes, the single quotes, the $() vs backtick debate — have a learning curve that resembles less a curve and more a cliff face with a narrow ledge halfway up where you think you understand it, and then you don't.
I once spent an afternoon debugging a script that was failing only when a directory name contained a space. The fix was four characters. The lesson cost me four hours. Bash will do that to you.
And yet. When I finally understood why word splitting works the way it does, something clicked about the shell's entire philosophy. It's a language built around text streams and the Unix process model. It's not trying to be Python. It's not trying to be anything except a thin, powerful wrapper around the operating system. Once you accept that, the strangeness becomes coherent, even elegant in a weathered sort of way.
Fish's friendliness is real, but it comes with a cost: the moment you write a Fish script and hand it to someone else, you've introduced a dependency. You've assumed they have Fish, that their Fish is the right version, that they've thought about Fish at all. A Bash script makes almost no assumptions. It assumes POSIX. That's it.
Portability isn't free, but neither is its absence.
The Muscle Memory Argument (and Why It's Not Just Laziness)
Here's where I'll admit something that sounds like rationalization but I believe is true: the value of knowing one tool deeply compounds over time in a way that switching costs obscure.
I've been writing Bash long enough that certain patterns live below conscious thought. Redirecting stderr, chaining commands with &&, writing a quick for loop over a list of files — these happen at the speed of intention rather than the speed of recall. That fluency took years. It was bought with exactly the kind of painful afternoons I described above, and with the slower accumulation of reading other people's scripts and asking why they made the choices they did.
Switching shells isn't just switching syntax. It's agreeing to go back to a slower, more effortful mode of working while you rebuild that fluency. Maybe the destination is worth it. For some people it clearly is. But I've watched colleagues make the switch to Zsh, spend six months configuring Oh My Zsh, and end up with a shell that's mostly Bash with a prettier prompt and plugins they don't fully understand. That's not a criticism — it's a pattern. We often optimize for the feeling of optimization.
Bash doesn't give you that feeling. It gives you a blinking cursor and expects you to know what you want.
The Thing That Actually Keeps Me Here
But if I'm honest — more honest than the portability argument, more honest than the muscle memory — why I still use Bash comes down to something harder to defend in a technical discussion.
Bash connects me to a way of thinking about computers that I find genuinely beautiful. The pipeline. The idea that every program reads from somewhere and writes to somewhere, and that you can compose programs the way you compose sentences, and that the output of one thought becomes the input of the next. That philosophy is older than I am and it still works. It works on my laptop, it works on a server in a datacenter I've never visited, it works in a container that will be destroyed in forty seconds.
When I write a Bash one-liner that does something useful — find . -name "*.log" -mtime +7 | xargs rm -f, say — there's a satisfaction to it that I don't quite get from a Python script that does the same thing in thirty lines. Not because shorter is always better. But because the one-liner is composed. Each piece is doing one thing. The shell is the glue. That's the Unix idea, and Bash is how most of us still touch it.
I'm not immune to new tools. I use ripgrep instead of grep. I've replaced find with fd in my interactive sessions. I reach for Python when a problem is genuinely complex, and I reach for Go when I need something compiled and fast. The shell is not the right tool for every job, and the people who insist otherwise are usually the same people who've written a 2,000-line Bash script and called it infrastructure.
But for the connective tissue of a working day — the quick automation, the file wrangling, the server spelunking — Bash is still where I live.
A Shell Is a Relationship
My 2014 backup script ran this morning. It will probably run in 2034, assuming I'm still around to need it and the machines haven't gotten so smart that backing up config files is a quaint human ritual. That kind of longevity is almost impossible to engineer deliberately. It happens when a tool is stable enough, simple enough, and embedded deeply enough in the infrastructure of computing that it outlasts the trends.
Bash is 35 years old. It has outlasted workstations, the rise and fall of several operating systems, the browser wars, the cloud revolution, and approximately eleven "the terminal is dead" think pieces. It will probably outlast the current enthusiasm for structured shell output and the next thing after that.
So when someone asks me why I still use Bash — and they do ask, usually with the gentle condescension of someone who has just discovered a newer coffee shop — I don't reach for the portability argument first. I think about that 40-line script. I think about the afternoon I lost to word splitting and what I learned from it. I think about the pipeline as an idea, and how Bash is one of the few places where that idea is still the whole point.
The question isn't really why I still use Bash. The question is what you lose when you stop.