Since no one has said it yet, please always use https://www.shellcheck.net/ on your scripts, you don't want to be That Guy https://github.com/ValveSoftware/steam-for-linux/issues/3671

Ah, wow. I like that they ported the accidental behavior deliberately into Windows:

Warning: The uninstallation process deletes the folder Steam was installed to to ensure it is fully uninstalled. If you accidentally installed Steam to a folder containing other data, for example C:\Program Files (x86)\ instead of C:\Program Files (x86)\Steam\..."

General recommendation specifically for the Valve-like case:

    set -o nounset

You can check variables as many ways you want, just do this too - safety net in case there's an eventual gap

shellharden is also great, that semi-automate the process to conform with shellcheck

I'm probably being too judgemental, but I don't get how people are so nonchalant about mutability and potentially destructive commands. Even in a Github Gist I'm scared enough to set -euo pipefail, put half a dozen checks before removing a folder...

Oh I do love reading those... Shame that shell scripting is still treated as mysterious command line voodoo, even Microsoft has Powershell now showing how powerful the concept is that even they couldn't avoid it entirely

You should also probably add either nullglob or failglob depending on your use case.

I would also add dotglob because it’s rarer for me to want only non-hidden files than it is for me to want all files.

This looks pretty cool!

I can't ever imagine using it tho :) If my bash scripts are so complex or critical that I feel the need to type check, I will probably use another scripting language where I can do that more easily while still having readable code.

If you ever check your arguments for any properties then this could still help, you'll have a systematic approach instead of an ad hoc one.

> the builtin types are:

> [...]

> boolean: a shortcut for returning a number (as numbers are booleans).

Can someone explain? I can understand booleans being numbers (e.g. #define TRUE 1 in C), but how are numbers booleans in bash?

Booleans in shell scripts are little more than zero (true) and non-zero (false) exit codes.

Ok, right. But then it should still say either "booleans are just numbers" or "numbers can be interpreted as booleans, i.e. are truthy or falsy".

It's not that cut & dry, as bash is doing evaluations; 0 and 1 can both be "true" if simply used without an evaluation, but add logic and it starts to matter (grep returns 0 if hit, 1 if not).

    [[ 0 ]] && echo "hit 0"
    [[ 1 ]] && echo "hit 1"
    grep -q 127 /etc/hosts && echo "hit grep"
    grep -q 128 /etc/hosts || echo "miss grep"

This is wild. Bravo to the author! (For the tool, and also for really funny documentation and commit history)

I used to somehow think Bash scripts were ideal given that they were fairly transparent, but I'll take a Go app or Rust program anyday now over something written in shell script. shfmt is an example.

Well, they are fairly transparent.

The problem is, they have a tendency to suddenly get horribly intransparent when they grow larger than maybe a few dozen lines.

>It is also a very cursed idea taken way too far, and I do not apologize for it

Agreed XD

It's a really nice idea but I cannot ever see myself writing bash like this