A shell colon does nothing. Use it anyway

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!

This is handy for quick scripting as a natural extension of a command line interface. A counterexample might be an equivalent script using the Python subprocess module. For a simple script, the required extra quoting overhead is not worth the trouble. For something complicated it’s essential and a shell script is no longer suitable. For something in the middle, a carefully crafted shell script (eg. one that passes shellcheck) may be the most suitable solution depending on the situation.

Both cases have their place. It’s about using the right tool for the job.

I don’t agree with this assumption that shell should use mechanisms we accept in “regular” programming languages, whatever that means. And why not the other way around? Why do we accept mechanisms in programming that we wouldn’t accept in a shell? There are layers of assumption in your assumption.

I also disagree with lumping scripting and programming together. Those are two different activities, and shell is better at scripting than programming, and it’s better at scripting than programming languages.

Try using python as your shell, and you’ll find out that python is fundamentally bad as a shell REPL. The shell is necessarily different from python or C++ or <your_favorite_programming_language>, starting with the ability to run command lines by typing them, with zero extra syntax. That is something regular programming languages can’t do, and it leads directly to the need for string substitution rules.

If you want a shell made out of a good programming language… make one! People have been thinking about this for decades and nobody has come up with a good one, because shell languages like bash are better at shelling than programming languages.

Posted from my phone since my system came crashing down.

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.

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}"

: ${DEBUG:=false}

debug is not only false, but garanteed to be set to something so that elsewhere the places that use it don't need extra syntax and checking in case it's empty, and yet you can just set it from the parent environment to override without touching the script or adding a commandline args parser.

And do me, reading this is almost as easy on the brain as just plain DEBUG=true.

Even if you aren't familiar with the extra syntax, like you're someone else in the future who needs to look at it, the two important words pop out, and probably don't mean NOT because whatever those extra bits mean, there's no !. So you get the idea well enough & cruise on.

...[edit] yep it's in the article. but one thing isn't, exactly

    condition && {
        then-cmd   # might exit > 0
        :          # ensure this block ends true
    } || {
        else-cmd
    }

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

different strokes of course.

I'd never call Python "portable" though if you have outside dependencies.

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

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.

Sometimes I feel like the people on HN repeating the trope "uhhh if you need ____ go learn a real language!" are just bad at writing shell scripts.

(...)

> 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.)

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!

  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.

Strangely though, I much prefer using the builtin "printf" to replace "echo" and "date", though the "date" usage is harder to read.

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.

<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.

I spend about 50% of time working time in the shell. I didn't find anything in TFA unreadable.

Your company likely started using bash before python was ubiquitous.

> 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.

  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