-
FWIW, I also made a tool like this: pyxxd
-
May I recommend putting in paragraph zero, “Use shellcheck, dummy!”?
-
It’s in the readme. The linked document is meant as an addendum. I’ll think about it.
Update: Added a preface.
-
-
I’m still waiting for a [any sensible/modern language]-to-bash transpiler that will be nice enough to use to become widespread.
-
Me too. I might attempt this at some point as an extension to shellharden.
Possibilities for a sensible/modern language:
- Fish - basically apply Wikipedia’s bash/fish translation table. Interstingly, every variable in fish is an array, so the corresponding bash code would be verbose (
$var→"${var[@]}"), but so be it. I’m a daily fish user, btw. - ion. I don’t know much about it.
- The hypothetical Oil language (andyc’s post above).
- Noob-style bash without quoting: Use shellharden as your transpiler. Hey, that’s possible today!
- Fish - basically apply Wikipedia’s bash/fish translation table. Interstingly, every variable in fish is an array, so the corresponding bash code would be verbose (
-
-
Quite a nice list! One thing that stands out to me is the
#!/bin/bashshebang, since I’m a NixOS user and it won’t work there (this is NixOS’s fault for not following FHS, but it has compelling reasons for doing so ;) ).I always use
#!/usr/bin/env bash, which AFAIK looks upbashfrom the currentPATH; this lets the user use their preferredbash(e.g. somewhere in~), or propagate an augmentedPATHthrough subprocesses (e.g.PATH=/my/favourite/bash/bin:$PATH ./my-top-level-script).By using
/usr/bin/envfor bash, python, runhaskell, etc. we only need to hard code a single path (which we can even special-case, e.g. with a find/replace, so the path itself doesn’t even need to exist!) -
-
Informative post about shell/bash syntax, with a focus on quoting. Nice first post, @anordal.
-
-
Special remark: Using curly braces is no substitute for quoting, so don’t pretend it is:
Extra bad (adds confusion):
${my_var}I actually completely disagree, and I would argue that you should always add the curly braces. I’ve never heard of anyone thinking curly braces equated to quoting, but I’ve heard of many, many people (myself included) who don’t know all the rules about what constitutes the boundaries of a variable name. (Quick: does
"$my-var"expand the variablemyormy-var?) The author actually stumbles upon one of these confusing cases further down ("$10"versus"${10}") and uses it to add a special exception to their no-curly-braces rule.-
Seconded. Always add the braces. I’ve also never seen (or even heard) of anyone confusing them with quotes. I used both braces and quotes. If anything, they make it clear that it’s a variable.
And you need to use them if you are expanding something like
filename${num}blah.dat. -
Maybe that wasn’t well explained. Whenever braces are needed to limit the boundary of the variable name, you can achieve the same by the placement of the quotes:
- Good:
"${my}-var" - Good:
"$my"-var
Thus, depending on where you like to insert quotes, you may typically end up removing curly brances when fixing bad code like the unquoted
${my}-var.The exception case needs quotes to extend the boundary of the variable name.
-
If you simply put every variable in its own set of quotes, you never need braces. Except for the exception.
You can avoid any exceptions by always using braces. It also clearly deliniates it as a variable in any context.
The only “good” one to me, of the ones listed above is
"filename${num}blah.dat", although all three are safe, so it’s really a style issue. (I realize this is different from my example which didn’t have double quotes but it was just for illustrative purposes.) I personally findfilename"$num"blah.datquite distasteful.The rest of the advice in the article seems reasonable to me.
- Good:
-
With sensible variable naming (a-z, A-Z and underscore) this should not be a problem and curly brackets should not be needed for regular variables. Reserving curly brackets for special cases also makes it easier to spot the locations where parameter expansion (like ${asdf%%asdf}) is happening.
-
-
People immediately think of std::optional as a great thing to return, but it isn’t. You lose the failure reason! Use a result type (a la rust) for that.
So why is Rav1e as slow as it is? How can it be sped up to real-time? Threads? Chunk-based encoding?
From what I understood from T.Daede’s presentation when it was new, is that its speed advantage comes from being brutally simple, such as only using the smallest transform.
The reference implementation is purely for accuracy, and doens’t care about speed at all.
They also don’t have
--releasein their README; I wonder if this number was created without it, if so, doing just that should show anywhere from 2x-100x improvements.EDIT: sent a PR for the README; they said their test scripts use it, so that must not be the case.