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