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.

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 }

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

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

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

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.

  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.

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.

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

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

We have some large bash scripts in my company, ~10,000 LOC spread across multiple files, all sourcing each other and what not. It is truly hard to read bash, which means it is truly hard to maintain bash, which means that when the one person knowing the bash scripts in your company goes away, you're in for some "fun".

My point is, these quirks are not useful, except for some bash enthusiasts.

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.

while : ; do case "$1" in "") break;; -f|-foo) shift; whatever;; *) usage; exit 1;; esac done

For this... instead

  if something; then 
     true
  else
     echo ERROR
     exit 1
  fi 

For anything else including json etc. I usually go to duckdb. Awesome support, single file install, readable, easy to maintain.

Powershell on Linux or Unix? Just another huge dependency if you manage 1000s of machines, and good luck finding a Linux gal/guy wanting or able to touch pwsh without chemical grade gloves.

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.

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

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

  if x then :; else something; fi

  if ! x; then something; fi

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

Btw, can the sequence :? be called "reverse Elvis" ?

This is one of those clever things, similar to people using perl5 use trinary expressions. Like, are you TRYING to make this obtuse and hard to read?

Shell scripts simply suck for many reason. They are ugly, verbose, convoluted, outright stupid too such as argument passing into functions. Then there is straight up retarded stuff such as case/esac. Whoever came up with that was clearly an incompetent language designer.