Hacker News

I feel the need to push back on this perspective.

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!

> fundamentally bad for scripting/programming […] a mechanism we wouldn’t accept in a regular programming language

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.

Your `$foo` example confused me at first because I thought the backticks are part of the example.

I will immediately remove all the shell scripts on my system based on this comment alone.

Posted from my phone since my system came crashing down.

Yes a large percentage of bash scripts fails if you feed them filenames with spaces or other special characters. Or a large amount of filenames near the Unix maximum commandline length.

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.

https://github.com/anordal/shellharden/blob/master/how_to_do...

Yo, author here.

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!

Agreed; author does note

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

"Shortcuts" like :? that tie together two unrelated things (checking a variable for a condition, expanding the value of that variable) drive me up the wall. It makes expressing just one of the two things harder than expressing both, leading to contortions when you want just one, like this use of :.

I use this for setting overridable defaults (this should hopefully actually be in the article I haven't read yet)

: ${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
    }

That seems unsafe. It assumes that the editor is started via a shell command, and not executed directly. But there is no actual binary /usr/bin/: but there is a /usr/bin/true; I would use that instead.

damn, nice one — definitely gonna use this myself (or variations thereof)!

nice dotfile

the people writing it are doing it for themselves probably. i wouldn’t expect it to survive a code review. the necessity of using esoteric bash features or syntax is a pretty good smell that you should be using something else imo.

different strokes of course.

This question seems to pop up all over the place, so I took some time to answer it here:

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

I believe you missed a semicolon after `exit 1` and before `}`. `}` closes the opening `{` only at the start of a command (POSIX rules; don't remember now if bash recognizes it when it's just a command argument).

I find Python a terrible bash replacement.

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

I hate weird bash tricks with a passion.

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.

It turns out that LLMs are really good at writing bash too. even perl! maybe we should rethink some of these lost bits because we no longer need to worry about the arcane parts.

I find LLM's too fall into the trap of writing a bash script for a task that clearly needs to be implemented in an Actual Language with Real Data Structures. For example, ask an LLM to bring up a SQL server with some schema + data preload step, and it will write a profoundly long bash script to do that task, every time.

Python startup time is a problem. I don't know about ts but I bet it's worse.

> 50000 footguns

(...)

> especially in the age of LLMs

Funny way of putting it.

But I think you are right still :)

Just use Fish

PowerShell needs to become more ubiquitous. There are so many things about it that once considered in greater detail make so much sense. Parameter setup, typing, and naming. Flow control. Object-oriented scripting. Built-in parsing for recursive data types like JSON, HTML, XML.

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.

DUDE!

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!

PowerShell is a bad choice for the system shell because it's too complex. I'm not trying to justify all the quirks of Unix Shell, but minimalism is a very important feature of such a tool.

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 still think that learning the shell environment makes a lot of sense these days. But mainly for interactive use. It's amazing the scripts your LLM can make you with, say, fd and fzf.

I can see crafting line by line when I’m retired or for a personal project. It’s eventually going to be like the people now who still operate restored manual linotype machines. “Look here I have the last functioning one in the midwest. See how the plates work…”

I prefer using "while true;" as that's easier to read. Arguably, it's less efficient due to calling the external "true".

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

They are NOT superflous, and all you need to prove it is `zsh` (but there are others that follow suit in similar fashions):

  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.

I was asking myself the same question and looked it up:

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

the fish shell manpage has ':' as an alias to 'true'.

I think colon at the start of a line was used for labels for goto statments.

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.

Absolutely!

Your company likely started using bash before python was ubiquitous.

Bash scripts should only be used for quick and dirty tasks where brevity is a major benefit. Don’t pretend bash can be readable and maintainable. If you want that use another language that sacrifices brevity for clarity.

Yeah, I don't see pwsh finding a place in the ecosystem. Even oil or fish struggle. Their place was mostly taken by python (which is a huge dependency but not another huge dependency).

I totally agree with you.

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

Stupidly terse code is fun and a good laugh to show to people as a puzzle… it is the opposite in an application that relies on it.

Hey jiveturkey, author here!

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!

The "if !" syntax isn't available on old enough shells.

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.

Aside: hacker news doesn't do markdown code blocks, but instead uses 2 spaces before text;

   if x then :; else something; fi

First of all, I must salute you on the joke; well put haha!

---

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.

https://www.gavi.org/vaccineswork/what-does-appendix-do-biol...

The trinary is semantically just an if expression though. Perl inherits C's problem that `if` can't be used in an expression context:

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

I like your 2026 perspective. Objectively, the posix shell syntax is genuinely bad, even though the overall system that it enabled is amazing. It's a very old system that took off because it solved a problem - history is kind to it because of that context. Though, awk is around the same age and provides a proof-by-existence that posix shell syntax didn't have to be make these mistakes.

Mostly agree, but many times there is no python nor ruby on a system, whereas there may always be shell available for scripts like these.

Ahh yes, that Bourne guy is clearly incompetent....

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