Please stop writing shell scripts

Y&#x27;all writing bash scripts without set -u and error checking?<p>One of the first technical docs I read online after discovering Linux was a best practices guide for bash scripts (or some similar version of these if my memory is lapsing)<p><a href="http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashGuide&#x2F;Practices" rel="nofollow">http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashGuide&#x2F;Practices</a><p><a href="http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashPitfalls" rel="nofollow">http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashPitfalls</a>

I&#x27;ve seen five line bash scripts replaced with thousand line python programs. In an extreme case a pipeline typed directly into slack was productized over weeks into some hundreds of lines of python that did the same thing. I&#x27;m going to keep using bash for trivial things.

This is not a BASH problem. Ok, well this example is, but more generally it is an example of an &quot;untyped&quot; vs. &quot;typed&quot; problem.<p>Types are the way to write software that has longevity. Even better, while writing software that is typed, learning of type errors sooner is better than learning about them later, and learning about them at runtime when your tools tell you everything is OK is the worst of all.<p>Statically typechecked languages win the day, here. BASH has value, Python has value, JavaScript has value, and typed languages all have more value, more longevity, and more provability than any untyped or dynamically typechecked languages.<p>Please use statically typechecked, compiled languages when writing load-bearing software.<p>&#x2F;soapbox

I love how the author airily mentions that python will be on your machine.<p>Some python, maybe, but which one? What a nightmare.<p>Shell scripts are extremely back compatible. And if it&#x27;s more than a few lines I&#x27;ll just, you know, write a program.

I have found that writing high quality bash scripts correlates with general competence. All of the issues mentioned can be mitigated once you actually take the time to learn how to use your tools. Instead, I read this as excuses for not learning how to code well, instead expecting the tools and languages to do the job that the developer should be doing.

So, the article describes reasons why bash is not good for shell scripts. Then describes some ways how to avoid them, using bash. Which kinda invalidates the idea that bash is a bad tool for scripting. You just have to know how to use it.<p>For me, I use both. For simple stuff I use bash. For more complex things I use a higher-level language. Like when I have really complex logic, structured data (I wish a new Linux shell would come up that can send objects through a pipe in a standard format like powershell can). Or when I need to do extensive chatting with a database or REST API or something.<p>Sometimes I use PHP (even locally), sometimes Python. On a Mac, PHP comes out of the box with some nice extensions that Python doesn&#x2F;didn&#x27;t offer out of the box on the same platform. So it was easy for me to do scripts talking to e.g. LDAP or some other things. Of course you can pull extensions in with pip but in my work we have a pain-in-the-ass MITM proxy that breaks most of that if it&#x27;s not set up correctly. So I tend to rely on pushing scripts that need nothing additional to run but the script itself. Also, pulling stuff in from public repos is a bad idea for security.<p>But for more simple stuff especially stuff that just ends up running other programs anyway, really there&#x27;s no point. Otherwise you&#x27;ll just end up with a row of shell() (PHP) or os.system (python) commands.

No, I won&#x27;t. Piping is a nice way to compose programs. I like that, just use shell check and proper settings.<p>I usually go to python or some other scripting language when I have a lot of string processing to do. For the rest something with a more advanced type system. Scala, rust and the like.

It&#x27;s a process that&#x27;s all too familiar to me - a script starts as a few lines of bash and very quickly turns into a few hundred lines of bash before being replaced by a few lines of Python. For some reason in my head I think &quot;this is so simple, Python would be overkill&quot; when in fact it takes more effort (for me) to do anything non-trivial in bash.<p>The real benefit of bash for me is that it makes it easy to invoke and bind together the many excellent tools we all know and love such as grep, sed, awk, curl, wget and so on. Chances are those tools can do their thing better than my hacked-together Python scripts can, so as long as I leave the heavy lifting to them and use bash only to shuffle text between them, a bash script can work well.<p>It&#x27;s true bash has a lot of gotchas, but it&#x27;s just a matter of knowing them. As an alternative to `set -e` I tend to use `somecmd &amp;&amp; echo &quot;Success&quot; || echo &quot;Fail&quot;`, and I usually explicitly check whether a variable is non-empty, as an alternative to `set -u`. Interested to hear whether these approaches have any major drawbacks as against `set -eu`.

Yeah, bash is ugly.<p>PowerShell however is my go to language for integrations. Its cross-platform now, can do anything higher language can (although that is not the point), any script is way shorter then equivalent [insert-non-shell-language-here] program, and you don&#x27;t need any toolset, just any editor. On any Windows its there OTB, while its one package manager command away from any Linux et. all systems, you have nice debugger in vs code etc.<p>I cringe when I have to leave that beauty because I must use &#x27;serious&#x27; language. It happens only when I need great performance. Number of integrative components far exceed number of any other components so I am very grateful to have this beast on my side all the time. From invoking REST API functions (Redmine, GitLab&#x2F;Hub, Grafana, Rundeck) or SOAP functions, over complete deployments and IaC, automatic tests in Pester, build routines via Invoke-Build, to data analytics and processing with ConvertTo&#x2F;From-JSON,CSV,XML,YAML, to parallel task invocations via multiple processes or threads etc... its all there and it all obeys clear standard. Epic.<p>If you don&#x27;t love it, you didn&#x27;t grok it.

This article seems to have been <i>started</i> from the position of &quot;I want `set -euo pipefail`&quot; and the points are just geared towards it.<p>And those options have big issues!<p>`-e` (&quot;errexit&quot;) can just kill a script for no obvious reason, and doesn&#x27;t even give a good error to figure out what happened.<p>`-o pipefail` makes it <i>worse</i> by causing pipelines to sometimes fail depending on how much input was buffered - the classic example is `something | head -n 1`. It also doesn&#x27;t give a proper error, and with errexit this kills the entire script.<p>`-u` is probably okay, but also triggers for `$1` and friends, so it basically requires you to write `${foo-}` everywhere. And if you&#x27;ve done that, you can still misspell your variable name.<p>See <a href="http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashPitfalls#set_-euo_pipefail" rel="nofollow">http:&#x2F;&#x2F;mywiki.wooledge.org&#x2F;BashPitfalls#set_-euo_pipefail</a>

I write most of my CLI tools in Rust. I don&#x27;t care for learning &quot;good bash&quot; like many of these comments are suggesting is the solution. It is not the solution.<p>You most likely work in a team of people. Expecting everyone to understand the nuances of bash and not get them wrong is wishful thinking.<p>Some people say that bash is portable, and maybe they&#x27;re kinda right, but the commands you use like sed and awk might have different args supported. Have fun supporting Linux&#x2F;mac (and Windows).<p>I use Rust because it most likely works if it compiles. The easiest way to right functions is usually the correct way to proper error handling etc. Also its what we use for our services anyway so people know it. The only issue is binary size, but that&#x27;s not a huge issue, we either just ship them in docker images or just store them in github releases where we can download them in CI

At least with a shell-script, you&#x27;re unlikely to get SHOUTY DEPRECATION WARNINGS that you can&#x27;t turn off.

I totally agree with not writing shell scripts.<p>As far as I can tell this person is trying to sell me python scripts. My personal take is that I don&#x27;t want that either, for almost exactly the same set of reasons. Just write the darn thing in whatever your real, main project language is (java, go, c++, whatever). I wouldn&#x27;t use python just for scripts unless all my stuff was in python, I think code interop and working with all the tooling you&#x27;ve already set up is too valuable.

Or maybe we should START writing shell scripts in Windows environments now that it is supported natively

I find shell scripts and one liners very accessible and intuitive, while I basically can&#x27;t do anything with a real programming language besides calculating numbers or printing text to the screen.

&quot;please stop writing shell scripts&quot; - no

A full-featured BDD unit testing framework for bash, ksh, zsh, dash and all POSIX shells<p><a href="https:&#x2F;&#x2F;github.com&#x2F;shellspec&#x2F;shellspec" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;shellspec&#x2F;shellspec</a>

right, guess I&#x27;ll go back to batch files.

So what should I use instead? Python? No, I write shell scripts because shell is everywhere. I might not know everything about writing bulletproof stuff but I do generally try to target posix shell.

This post reads like a preachy Reddit post. Don’t tell me what to do!

Has anyone here had any experience with using Google zx?

Dear dang, does this qualify as a flamebait post?