Bash/Sh is an objectively awful programming language. You could likely fill an entire book with all of the design fails that is Bash script syntax. Only in a shell script would you ever need eight backslash characters in a row in order to accomplish something...and "space as delimiter" is awful in <i>so many ways</i>.<p>But especially Sh runs everywhere, so it's good to know. This seems to be the article's point.<p>Honestly, though? The right answer is to transpile a better language to Sh.<p>Looking around, there have been several half-hearted, abandoned attempts. But apparently everyone is happy to just fall back on the "accidental syntax" of Bash that really doesn't make sense when compared to ... any other language.<p>I put up with Bash because there's no better alternative. That doesn't mean we <i>should</i> put up with Bash; just that we <i>must</i> put up with it at least to the point where it can run code written in a <i>real</i> language.
This article is not specifically about Bash, but about the shell command language sh. The POSIX Shell is a standardized subset of Bash which has even better portability. I would recommend learning and using sh unless you really need Bash.<p><a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html" rel="nofollow">https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...</a><p>Your script will use sh if it starts with #!/bin/sh (instead of #!/bin/bash).<p>I can also recommend ShellCheck which is a shell script analysis tool (implemented in Haskell) which can find errors and potential problems in your scripts. On a Debian system, installing ShellScheck is as simple as `sudo apt install shellcheck'.
BASH is like Obi Wan. It isn’t the most powerful or flashiest, but it survived a long time, where others didn’t, for very good reasons. Bash runs basically everywhere. It has many modern features you wouldn’t expect. Its syntax is literally what you would type on the command line if you were diagnosing or fixing systems so you don’t need to transpile to another language. Its reliance on other programs means it is glue and can easily incorporate highly cohesive functionality/tools others write and maintain. Also, it’s been around and is everywhere so you don’t worry about trying to incorporate the current latest and greatest declarative tool (which will blow over in 5 years) into your other workflows. Basically, don’t disparage a Jedi/tool that has survived where others didn’t. There is a reason.
The only real advantage of bash (or other shells) is the ability to build up to it from the command line; to use it as a REPL then embed the stuff you've just done into a script.<p>The massive disadvantage of bash is that it uses a legal filename character " " as a delimiter ("$IFS"). That means it's very easy to write scripts which work fine on your test case but blow up in a different context. And the worst case of that is accidentally deleting the user's file system.<p>So many of the cute little bash examples you'll see, including I think the awk one on this page, will go wrong if you have a space in the wrong place in your filesystem. Or, god help you, a newline. Or a file named "*". Or "--".
I have a counterpoint for many comments here. If you are writing some Python for example, and most of your code is executing commands such as tail, cat, wc, etc. and then doing something with their output, you are better off writing a shell script instead .
I'm a computer scientist/software engineer that has used primarily Unix or Linux systems since the 80's. I write shell scripts occasionally, but I just find them error prone enough that I'd rather use python than sh for complex scripts. Python has some packages that make working with files, directories, and processes tolerable and at least I can understand the string quoting rules in python.<p>Generally my order of preference for shell scripting tasks is: python > bash > pearl > tcl > sh > anything > AppleTalk.
This argument isn't very compelling. Shell scripts are great at tricking you into believing you've got something 100% working when in fact you've only accounted for the happy path and maybe two or three failure cases. This is the primary reason shell scripts are so often broken. There are tons of assumptions baked in which are easily violated.<p>If your shell script keeps breaking, and you keep fixing it by writing more shell, then you're in an abusive relationship with your programming environment.
I feel like zsh is for pros maybe. I use Linux daily and write python and shellscripts. Zsh has been defaulted all over the place but all that meant for me is I have to figure out how to get it to do things the bash way once in a while.<p>I see no reason why distros like ubuntu or kali would default to zsh.I use the shell for sysadmin stuff, anything complex or app specific gets at least a python treatment.<p>The whole thing reminds me of python 2->3 or sysv init to systemd. There must be people somewhere deeply invested in these changes and their voice is certainly much more valuable than the average opensource joe user. Defaults matter and the time I and millions had to spend learning to transition for no direct benefit to us has value. The whole distro model of everyone getting a distro they like falls apart when not enough people can fork.<p>Overall, this devalues opensource as an investment. Because of unpredictable hidden costs like this.
I think this perspective is essential in our ever-evolving tech industry. Bash, despite its quirks and often steep learning curve, has its niche in our toolset.<p>Its power lies in its simplicity and direct access to system level functions, which makes it an efficient tool for system administrators and developers working in DevOps. It's excellent for automating small to medium-sized tasks on UNIX-like systems where the overhead of a full-fledged language would be overkill.<p>While it's true that bash has its limitations, the value of its ubiquity cannot be overstated. The bash shell is everywhere - from massive server clusters to tiny embedded systems. This means that a bash script written on one system is very likely to work unchanged on another.
The article is a bit confused about whether it's making a case for shell scripting in general, or for the Bourne Again shell in particular. By the looks of things, its target readership is people who don't use shell scripting, or interactive shells, <i>at all</i>; so the former case would be more appropriate, and the drawing of a distinction between the Bourne Again, Friendly Interactive, Z, and other shells just muddies the waters for that readership.
it seems like most people that have dislike bash never spent the time to learn it.<p>I have a love/hate relationship with is. I started with computers in 2000 and wrote a ton of bash for various things. Compiling software, running cicd, adhoc batch jobs, etc.<p>I've managed many cicd pipelines with bash in my time. While it's not great, once you know the basics, you can be very successful. That being said, rewriting the bash "program" in another language is much advised. If your bash is over a few hundred lines, chances are you've outgrown it<p>Some things in bash (mainly pipes and redirection) are just too easy. Job control is also great. The 'process' and 'shell script' are two primitives that make a lot possible.<p>Trying to do pipes or redirection in python is awful. There are a ton of subtle bugs you have to worry about
The thing that makes me loathe Bash more than anything else is it’s 3 types are string, int, and list and those are not the only types of data I work with day to day.
We should have better local shells that “drive” remote sh/bash shells through transpilation, so that we can have modern shells anywhere without concern for remote install, access to install or compile, compatibility, carrying customizations, etc.
IMHO, the best resource to learn about both Unix shell usage at the command-line prompt, and shell programming in .sh script files, is still the book "The Unix Programming Environment" by Kernighan and Pike, except for shell gotchas and subtleties which were discovered later.<p>Of course, they still would not have covered all possible issues known even at that time, because that was not the focus of the book, which was to be a Unix tutorial, not just on shell, but many other commands, general Unix usage, and the environment too (hence the title of the book).<p>But they did cover and warn about some issues, including giving solutions.
> It coordinates programs…<p>Sounds like a case for shells in general. No other script-execution tools make running other programs (and linking their inputs and outputs) so simple.<p>To overcome Bash’s problems, one can choose another shell. But I suppose you can’t just pick your personal favorite and script in its dialect, because then how would the human tasked with integrating the script into $wherever know which shells to have installed? You can stick with sh which is guaranteed to be installed, or bash (indeed an improvement over sh) which is nearly guaranteed to be installed.
Maybe this already exists, but I imagine if someone wrote at library for interacting with gnu or posix commands from python (or ruby, or...) that built up the commands in a structured way and parsed the replies and put them in a dict, that would be very nice to use instead of bash-scripts. Every weird thing that you wanted to do would be a lot easier to do in python than in bash, and none of that looking out for spaces in strings and so on.
I’ve written a ridiculous number of shell scripts to automate many many things. It’s great for doing something now, and it’s great as a way to interact with a machine. It is not great in all cases. Particularly: array handling is bad, it’s slow if you start using actual Bashisms, very few younger devs seem to know it.<p>The shell is great cuz it’s there and it can cover about 50% of use cases for server side automation, but it’s bad for the reasons mentioned above.<p>I love it and I hate it.
Am I missing something or is the article's central example using `tail` fundamentally broken?<p>The `sort` blocks until input is closed yet `tail -f` never closes its output.
As a serious programmer, I have printed out and read most of the bash v5 manual.<p>As a serious programmer, i do TDD even with bash, it is called bats-core<p>As a serious programer I use the right tool for the right job, so I write bash scripts when it makes sense.<p>Having done all these, I rearly write bash programs, but when I do, it is a joy! Plus i have gteater terminal understanding which is useful beyond bash programming.
> The Python and Ruby versions would be similar<p>Not Ruby!<p><pre><code> sh = Shell.cd('/')
sh.transact do
system('tail -fq /var/log/nginx/access.log') | system("awk '{print $7}" | system("sort") | system("uniq -c") | system("sort -rn")
end
</code></pre>
Pretty sure one could get without the system method with Shell having def method_missing(meth, * args) to call system([meth.to_s, * args]) or something, turning it into:<p><pre><code> sh.transact do
tail '-fq' '/var/log/nginx/access.log' | awk '{print $7}' | sort | uniq '-c' | sort '-rn'
end
</code></pre>
<a href="https://github.com/ruby/shell#pipe-etcprintcap-into-a-file">https://github.com/ruby/shell#pipe-etcprintcap-into-a-file</a>
So it's both ubiquitous and a terse DSL for managing and coordinating programs. Yeah I agree. Also if you're on Windows it's nice that PowerShell is always preinstalled and serves the same purpose.
1. Someone creates a platform.<p>2. They make a terrible language the most convenient language.<p>3. People use the platform, along with the terrible language.<p>4. This terrible language is now everywhere.<p>5. The argument for using this terrible language is #4
> This is a contrived example<p>Indeed, in JS you wouldn't use awk and sort, you'd use JS array functions. It's fine to have examples that are contrived in the sense that the problem is contrived, but the solution should not be.
Good points. But I wish Bash had better syntax and built in support for basic concepts like boolean logic. Try to compose some complex boolean expression in Bash and you will quickly hit problems.