Same. As soon as I read the title: "Surely `sshpass` still works in this instance? Yup."
Even if avoiding good practices with PKI was defensible (and it definitely is not), further avoiding `sshpass` in favor of this more contorted trickery is (imho) probably the wrong choice.
On the other hand, text-based line-oriented APIs are a force multiplier that lets one solo dev/sysadmin be capable of administering (troubleshooting and building out and keeping alive) far more infrastructure than can be reasonably expected. And it's not sysvinit you should critique, but runit (fast and bulletproof - two things the other modern alternative doesn't really do).
> Ignoring failures because they're moderately unlikely is the hallmark of a bad developer.
I dunno I think something like JSON would still allow solo dev/sysadmins to get a lot done without the risk and effort of having to hand-roll separate parsers for every API. Then you could also offer something like Fuchsia's FIDL for programs to interface with - it allows generating the interface code fully typed in whatever language you want. No need to hand-roll a parser at all!
> runit
First I've heard of that. Looks interesting, but it doesn't seem like it has nearly enough features to run a modern desktop system? It just starts daemons and keeps them running as far as I can see.
I'm not familiar with Fuschia's FIDL system, but it looks intriguing. Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text. If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier. Ha.
Runit is pretty good - it's the default in the Void Linux OS that I use on my personal machines. Definitely good enough for a modern desktop system, though it's not aimed at the same crowd as Ubuntu and Fedora.
> Though it's still pretty hard to beat using pipes and cut to ingest a line-oriented stream of text.
Well, a) that's fine for interactive use but awful for unattended use because it's so likely to go wrong, and b) it is actually pretty easy to beat that - JSON and jq is much easier, nicer and more reliable. Or Nushell/Powershell structured pipes. Or an autogenerated properly typed Python interface. Take a look at /proc/self/status before you tell me you'd rather use some awk/cut monstrosity than `jq .ppid`.
> If Fuchsia had beaten out UNIX in some parallel universe, it does look like we'd all be happier.
I'd definitely be happier - I wouldn't spend so much time debugging why Linux stuff breaks!
1) How are shell scripts janky? Could you elaborate on that? Obviously if someone doesn't know shell very well they will write suboptimal scripts. Personally I use runit init, which uses shell scripts for services and it works well.
2) No idea where you got that from, I never had a problem with this (as a full-time Linux user)
3) Mixed opinions on this one. There's a ton of various info in /proc that could theoretically be exposed via different syscalls, or maybe a single syscall? But having a text-based API in this case isn't a big issue really.
1. Sounds like you have written very few shell scripts if you don't know the issues and think you can just "don't make mistakes" (a classic fallacy). You can Google it and there are a ton of articles. Here's the first one I found which is decent but doesn't even mention some big issues like quoting: https://pythonspeed.com/articles/shell-scripts/
2. Try putting a space in your home directory and let me know how that goes...
3. Most programs don't resort to reading /proc or /sys because it is such a pain! I bet there's a ton of undiscovered vulnerabilities in programs that do.
1. The real fallacy here is assuming "it requires experience so it's impossible to do". Everything described in that article is trivial and anyone with experience in writing shell scripts knows about these things. People just instinctively go "this doesn't do what I expect therefore it's bad" instead of trying to understand the reasoning behind that. tl;dr Classic skill issue
2. Another fallacy. Obviously there will be badly written programs that don't handle paths properly. And I'm sure that if I put a space there it will screw things up. But it doesn't mean that most programs do that?
3. It's not a pain. It's absolutely trivial to do, and people whose code is vulnerable in this case are most likely just bad at programming and shouldn't be writing at such a low level as to cause vulnerabilities anyway. These are the type of people referred to as "developers" instead of "programmers". (Source: I personally parsed /proc entries without third party libraries, can't say it was hard)
> anyone with experience in writing shell scripts knows about these things
Who wants to have to be an expert in shell scripts to have to write them? In any case you're still wrong. Experts aren't immune to footguns. Post a complex shell script you've written. Let's see.
> Obviously there will be badly written programs that don't handle paths properly.
Like GNU Make?
> It's absolutely trivial to do
Trivial to do so that it works for you. Absolutely not trivial to do so that it always works.
The types of people who know the difference between those are referred to as "senior" instead of "junior". (Source: I personally parsed /proc entries too without third party libraries and there were plenty of footguns that a junior developer would skip over.)
> Who wants to have to be an expert in shell scripts to have to write them?
If you aren't good with shell scripts, why bother? Go use Python or something else entirely. And it's not like you would use shell scripts to write all your programs, they aren't suitable for anything more complex than stiching a bunch of programs together anyway, yet people still try. And then those people complain that shell script is full of "footguns" when they are misusing it.
> Trivial to do so that it works for you. Absolutely not trivial to do so that it always works.
No idea what you are on about, literally every single detail you need to correctly parse /proc entries is in proc manpage. And yes, if you wrote your parser correctly it will still work between kernel versions, because /proc is considered a stable API between the kernel and userspace (same as syscalls). There are no "footguns" and no mysteries to it. It's a solved problem. Provide a concrete example of a footgun if there is one, and by "footgun" I mean something that isn't clearly stated in the manual that everyone dealing with /proc reads (right?)
You have a fundamental misunderstanding of footguns, and humans. Explaining them is in manual doesn't mean they no longer exist. People often don't read the manual. Nor should they have to.
> If you aren't good with shell scripts, why bother? Go use Python or something else entirely
I agree! And given that essentially nobody is "good with shell scripts" we can simplify that advice to "don't write shell scripts".
> People often don't read the manual. Nor should they have to.
That's some kind of logic right there. If people don't read the manual, they have every right to expect that things will break. It's not surprising or shocking, it's just user error.
> we can simplify that advice to "don't write shell scripts".
No, we cannot simplify it like that. Shell scripts are a brilliant tool for a certain kind of problem, and they work well when used for that class of problem. When used for anything else, they work poorly. Same applies for literally any other tool. It's like saying "essentially nobody is good with a CNC machine so don't use it"
