For example, what does `$foo` mean in shell syntax? In any reasonable language (perl or powershell, for example, or python if you drop the `$`), it's an expression that evaluates to whatever value's inside that variable. In shell, `$foo` isn't an expression in that sense, and what it does depends on what's inside it via a variety of string substitution rules.

This is the main reason we have arcane articles like this.

That said, nice article.

However, the only one I already knew...

    if some-command; then
        :                            # command required
    else
        echo "command failed"
    fi

    if ! some-command; then
        echo "command failed"
    fi

> If the pipeline does not begin with the "!" reserved word, the exit status shall be the exit status of the last command specified in the pipeline. Otherwise, the exit status shall be the logical NOT of the exit status of the last command

    : "${1:?missing argument, aborting!}"

Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in useful if you are going to extreme lengths to avoid dependencies outside of the shell.

Example:

  foo(){
    : "This is a docstring for the foo() function"
    bar --verbose | baz --quiet
  }

I have an alias[1] for that which I call a quick interactive rebase:

    riq = -c sequence.editor=: rebase --interactive

[0]: https://domi.work/blog/posts/compose_polyglot/

    [ -z "$1" ] && { echo "missing argument, aborting." 1>&2; exit 1 }

    1. Everyone wants the colon.
    2. Larry gets the colon.

Switched from bash to plain python scripts for shell stuff everywhere several years ago, and never looked back into bash zoo anymore. Stable syntax across Win/Mac/Linux, no bash/zsh/msys2 obscure differences, normal errors and Clause writes scaffolds quick and flawless anyway

Some of the examples here are interesting, but they show parameter substitution more than colon itself: https://tldp.org/LDP/abs/html/parameter-substitution.html

In small scopes, I tend to inline the `:?` validation inside the arg of the command. `echo "${1:? first param required}"`

Another usecase is to use colon in the body of a while loop, while doing work in the condition of the loop.

    while rlwrap -o -S'>> ' tr a-z A-Z ; do :; done

I've also written about this and other bash tricks over the years in https://github.com/kidd/scripting-field-guide/blob/master/bo.... You might like them :)

- it creates the file if it does not exist, not merely truncate. as a tutorial kind of blog post this incomplete description matters IMO.

- it would work the same without the colon (similar for default variable assignment examples). we generally strive not to have "extra" things, like useless use of cat.

- educationally it's useful to demonstrate that redirection, like parameter expansion, works before the command executes (the null command in this case), but the article doesn't explain that at all!

otherwise i <3 this article. some uses of colon i had never thought of or seen before. like file truncation, not sure i'd use them but it was cool to see them.

  param(
    [parameter(mandatory)] $name
  )

  "Hello, $name!"

  $ ./script.ps1 Dave
  Hello, Dave!

  $ ./script.ps1 -name Dave
  Hello, Dave!

  $ ./script.ps1
  cmdlet script.ps1 at command pipeline position 1
  Supply values for the following parameters:
  name: <cursor here>

  $ pwsh -nonint ./script.ps1
  script.ps1: Cannot process command because of one or more missing mandatory parameters: name.

After a while, you probably know more commands and utilities than you know what to do with, and you'll forget they exist when you need them. In order to not waste time looking for a program for a particular and infrequent purpose, I create "do nothing" aliases like `: alias f3probe` so I can realize I just forgot I already have something for it. Nice predictable pattern to grep with `^: alias` to look through all of these.

I'd reject the pull request. Bash is already bad as programming language (the goodness of language for long code is inversely proportional to how nice it is for shell one-liners), this is just turning "bad" into "line noise"

If your bash script takes more than one screen, rewrite it in Python, hell, rewrite it in Perl, even that's better

  >file1 >file2

  : >file1 >file2

According to https://www.in-ulm.de/~mascheck/bourne/ SVR4 (1989) had a bug when using this method in a for or while loop and this bug showed up in a SunOS 5 variant, too

Apparently, early in the shell's evolution, : was used as a comment marker before # was added

Single quotes could be used to prevent undesired behaviour

   : echo output 1>&2

   : `echo output 1>&2`

   : '`echo output 1>&2`'

   if false;then :;fi

  : "${DOTFILES_PATH:=$HOME/.dotfiles}"

Also, I'll never use it.

Because a language feature that needs marketing is against readability, among those in my target audience who have not yet read the marketing.

I need my shell scripts to be long enough to explain to my audience exactly what they are doing.

The other day there was a blog post about learning SIMD. I think in future "programmers" will just nag about the speed of the program and the coding assistant will eventually introduce SIMD to the source code.

It is a little sad but we have to go with the current if we want to survive.

The subshell execution parentheses and the colon are superfluous here, just:

   < dataset.json && echo YES

> ( : >> result.json ) && echo YES # is result.json writable?

As a go-to idiom for a writability test, it gives me pause. If the file didn't exist, we created a zero-length one. That might be okay if we are going to write to it anyway as the next action.

If we are testing because we intend to overwrite it, why not just "> result.json" (which is by itself an idiom for truncating a file to zero length).

When would we every do this? Maybe before some command which takes the file name as a destination file argument rather than using output redirection, and which performs a lengthy computation before trying to open the file for writing. We can catch the permission error early.

I don't think I've ever coded such a test; normally you just do the operation that writes to the file and let that fail.

In POSIX C, there is a function access() for doing these kinds of tests. But it has a special purpose: it is meant to be used by a setuid root process to perform a permission test as if it were the real user/group (the one which elevated privilege to root). I.e. it's not can we do this operation, but should we do this operation (would we still be allowed, if we dropped privileges back to the original user).

It's almost but not quite in the article. And you don't necessarily always want this. It depends if you want else-cmds to run only when condition fails, or when either condition or then-cmds fails.

You could write the word true instead of :, coincidentally showing that : never really was a no-op in the first place. It's so not-no-op that there is even an entire external executable /bin/true to do the same job.

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

One-liners are a cool little artifact of early shell culture & are sometimes still useful today if they're short to avoid the readability problems of `/` when copy pasting a quick shell command to run, but they have no place in scripts.

None of this seems useful to me.

> if you are like me and prefer less typing (gotta go fast)

Yeah, no.

And now I see this article. So I guess that it is a construct suddenly popularized by llm.

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
    }

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.

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

  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.