At 2023-01-02T10:12:42-0800, Larry McVoy wrote:
You are talking to a dude with 40+ years of Unix
experience,
I'm clocking 30 this year. A babe in the woods.
supporting commercial products most of that time. I
didn't get "lucky
at Russian Roulette", I wrote scripts that were portable. I have 40
year old scripts that _still_ work and they work on virtually every
Unix ever built. How do I know? I was a contractor for my first job,
I got plopped down in front of every random unix you could imagine and
each time I polished off the warts.
Yes. That's how the chapter of the GNU Autoconf manual to which I
linked got written--or so I surmise, based simply on how bizarre some of
the bugs are that have to be worked around.
I spent decades supporting my own products on every
flavor of Unix and
processors from Arm to System/360. Oh, and Windows XP and on and
MacOS.
My scripts worked with /bin/sh being whatever it was.
It's interesting to me that other old timers, like Clem, are saying
exactly the same thing as I am. Are we all wrong?
Over on the groff list you had the opposite advice regarding Make: pick
one implementation and go with it, you said, and other implementations
be damned (very loosely paraphrasing).[1]
I'm not saying you're wrong--I'm saying you're inconsistent.
I reckon you did what you needed to do to keep the lights on and the
engineers fed. That's fine, but it's also a recipe for passivity. You
don't have to tell me, but count up the number of times you flexed to
accommodate a buggy implementation versus telling your client that their
shell was just too crap and that they needed to either install one in
which you had confidence, or you'd have to decline the contract.
If their users had demanded more of their commercial Unix vendors, maybe
those Unices would not be regarded as dinosaurs today.
I could harp further on quality of implementation issues, but I'd
probably do better to take up the lotus position on the back of a
motorcycle.
Preferably not while the vehicle is in motion.
Regards,
Branden
[1]
https://lists.gnu.org/archive/html/groff/2022-03/msg00084.html