bonkabonka

Yow, submitter sure isn't shy with their bias. Maybe defang the title?

I wish some clever person would make a sort of modern-day kali.net where you could easily route game traffic over Wireguard so your self-hosted Minecraft of Valheim servers don't have to be accessible on the public internet.

I would prefer to use the --json flag to provide syntactic sugar for setting the content type and accepts headers and leave the marshaling of data to a separate tool. Or if it has to be baked in, refactor `jo` into `libjo` and a CLI wrapper so that the two tools behave the same way.

I mostly use `jo` to format JSON from the CLI (except when I have to use `jq` to do so and then I suffer).

Except if it's an enterprisey distro, it won't get updated. Specifically RHEL 7 ships 7.29.0 and cherry-picks features (TLS handshakes) to backport to their nine-year-old version.

Unhappily RedHat won't. Heck, RedHat has gone well out of their way to backport updated TLS handshakes (1.2 at least) to their 2013 version (7.29.0) of curl.

To guard against malicious filenames I use `find ... -print0 | xargs -r0...` since posix disallows null bytes (and forward slashes) in filenames. The `-r` flag on xargs means it doesn't execute its command if find matches nothing.

So filenames can contain valid commands delimited with semi-colons that, if not quoted properly, can be unexpectedly run alongside your intended pipeline (say if you're doing the usual and unsafe "for csv in *.csv; do cat $csv; done").

I wish I could've laid my hands on the excellent HN thread from some years back that opened my eyes to this vector, but I'm hopeful someone else will mention it so I can add it to my bash notes file. :P

The original example MUST be corrected for the same reason that folks who post naive code snippets adding SQL strings together with user input must be corrected.

It is not a matter of taste and it is not a matter of metric versus imperial screwdrivers. Someone will copy this code and it will end up being an attack vector where it will have consequences.

I imagine you're rolling your eyes and have flipped the bozo bit but please bear with me.

Think of the teachable moment this presents! The author of the original piece goes back and annotates their original answer along the lines of, "you might solve it this way but there are some gotchas with it - let me show you what could go wrong."

As an industry we absolutely need to circle back with improvements so that those who come after us can build on a more solid foundation.

Other than the logo on the plane, of course. :P