Old doesn't imply arcane. It instead can (and does, in this case) mean that it won out over the course of decades against other less worthy alternatives.

Although you can write "programs" in sh, the shell syntax was never meant to be anything like a systems or application programming language. It was meant to efficiently automate systems tasks. It is kind of like the fork lift of computing. It does it's job very well, is bad at doing anything else, yet no other kind of vehicle can do it's job nearly as efficiently.

Comparing the shell to C, Go, Rust, Python, or JavaScript is crazypants. It has a different job than those, so of course it will look and feel different!

Bash et al are great for command line use, but produce a situation of really bad engineering hygiene when used in scripts.

Do not use. Stay away. Bash et al considered harmful. Red flags on job interview when referenced.

Posted from my phone since my system came crashing down.

You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic.

Thanks for your feedback, much much appreciated!

> Why use the null-command when I could do VAR=${VAR:-default-value}?

and points out it's one less thing to typo, but that assumes the name is the same; I like e.g.

  TARGETFILE="${1:?need input file}"
  OPTIONALVAL="${2:-defaultvalue}"

https://refp.se/articles/your-shell-and-the-magic-colon#why-...

The extent to which the script author gets to feel smart and efficient is exactly the extent to which the future reader of the script gets to feel like an idiot.

Calling all the command line tools is cumbersome, the Python cloud APIs are verbose compared to the cli tools and often have very different concepts for how they interact with services.

But I agree that there is a need for a better bash and zsh is nice but not the upgrade that is needed

  zsh% echo "hello world" > data
  
  zsh% < data && echo "READABLE"   # <- will print the contents of data
  hello world
  READABLE
  
  zsh% : < data && echo "READABLE" # <- this will not
  READABLE

---

and given that we use the null-command, it _WILL_ behave different with or without subshell.. and all you need is `bash --posix` to prove it:

    % cat subshell.sh
    #!/bin/bash --posix
    ( : < missing.json ); echo AFTER    # <- will echo AFTER
    
    % ./subshell.sh
    ./subshell.sh: line 2: missing.json: No such file or directory
    AFTER
    
    % cat no-subshell.sh
    #!/bin/bash --posix
    : < missing.json; echo AFTER        # <- this will not
    
    % ./no-subshell.sh
    ./no-subshell.sh: line 2: missing.json: No such file or directory

    % : ^- apparently.. there is a difference

---

One should never trust things just because they are written, but that also applies to comments on HN. Originally when I read your message I actually thought I made a mistake, I was very close to writing an apology comment and adding a note to the blog post, but not close enough - I had to test it again.

I'm thankful for the watchful eyes and scrutiny when reading things online, that's good - keep it up, but your message is factually wrong - on so many levels.

(...)

> especially in the age of LLMs

Funny way of putting it.

But I think you are right still :)

And in my opinion, the most slept-on: the fact it runs on the CLR and direct access to .NET objects and types which means access to P/Invoke and thence the Windows API. One can write business logic in the fast language and write a nice CLI wrapper around that in the natural shell language, and not worry about painful FFI unlike everyone else trying to fit Python or Bash into whatever world they're using.

The typical counter to this will be: PowerShell is verbose, PowerShell used `curl` as an alias to Invoke-WebRequest instead of the Real Thing™. Neither are real arguments.

I wrote my first real `.ps1` the other day for auto-installing all dependencies needed to run a `gitea`-runner on windows for windows builds; powershell - felt like the lover I never had. And the documentation in readable comments at the top that just.. generates usable docs? Damn, damn, damn.

There is a part of me that low-key wanna try that as my daily driver for a week or two. But with that said, I'm a zsh vi-mode guy - always have been, always will be.. but I'd happily take powershell on a romantic getaway every once in a while!

Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinely fail on boot and during normal operation. Stamping them all out is an arduous... well, basically, an impossible task for practical purposes where releases are expected to come on time, where users may manipulate configuration in gazzilions of unpredictable ways.

PowerShell is just another language in the same box with Python, Perl, Ruby and many like that. It's not a good language, if you decided to reach for that box. Probably not the worst either.

System shell, however, isn't meant for writing entire applications. Writing applications with elaborate command-line interface should be left to languages that can properly address this problem. PowerShell is trying to be there, but it doesn't hold a candle to its "older brothers" who can, indeed, design a very robust command-line interface, often using a dedicated library for it.

PowerShell appeals to the novice crowd who are very enthusiastic about automatic checks in their code: the benefits are on the surface, the downsides are difficult to assess. This is in line with other Microsoft software products / languages which target novice programmers by implementing as many as possible of the highly-advertised features without regard to the overall usefulness of the product (think about C# or MS Office suit etc.)

Your company likely started using bash before python was ubiquitous.

<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...>

The most important differences seem to be:

* `:` is a builtin vs. `true` is an utility * passing arguments to `:` is safe but for `true` its not hence `:` is the right thing to use here.

https://www.in-ulm.de/~mascheck/bourne/PWB/goto.1.html

  DESCRIPTION
     Goto is allowed only when the Shell is taking commands  from
     a file.  The file is searched from the beginning for a line
     beginning with `:' followed by one or more  spaces  followed
     by  the  label.  If  such a line is found, the goto command
     returns.  Since the read pointer in the command file  points
     to  the  line  after  the label, the effect is to cause the
     Shell to transfer to the labelled line.

> the goodness of language for long code is inversely proportional to how nice it is for shell one-liners

Well, except for this bit. Oil or fish and awk are perfectly fine for one liners but don't repeat the mistakes of posix shell syntax.

Probably not an issue for most people in 2026 -- you have to back pretty far for it to be missing. Technically, though, "if x; then :; else" is more portable.

   if x then :; else something; fi

---

It is a (contrived) example of usage where a command is required and `:` can fill in the blanks. There are certainly scenarios where negating an expression becomes harder than doing the "dumb" way, and I for one has written code where `:` can be used as a placeholder meaning "fill this in later" or equivalent.

With that said, 100% agree with you that in actual "production" code - there is always a cleaner way.

I agree with you, and for what it's worth the truncation snippet is very much tongue-in-cheek much like `( : >> output ) && echo "is writable"`.

I wasn't expecting anyone to actually use these in Prod, rather I aimed to show what can be done with a command designed to.. do nothing (crazy).

Happy you enjoyed the article, and thank you!

  my $x = if ($cond) { 1 } else { 2 };  # Syntax error

  my $x = $cond ? 1 : 2;

Something like the code below is hard to read:

  my $fee =
    $is_member
        ? ($is_student ? $student_member_fee : $member_fee)
        : ($is_student ? $student_fee        : $standard_fee);

  my $fee;
  if ($is_member) {
      if ($is_student) {
          $fee = $student_member_fee;
      }
      else {
          $fee = $member_fee;
      }
  }
  else {
      if ($is_student) {
          $fee = $student_fee;
      }
      else {
          $fee = $standard_fee;
      }
  }

  my $fee =
    if ($is_member) {
        if ($is_student) {
            $student_member_fee
        }
        else {
            $member_fee
        }
    }
    else {
        if ($is_student) {
            $student_fee
        }
        else {
            $standard_fee
        }
    };

https://en.wikipedia.org/wiki/Stephen_R._Bourne