17 Jun
2024
17 Jun
'24
7:25 a.m.
On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote:
"Greg A. Woods" <woods(a)robohack.ca>
writes:
This is sort of off topic but maybe relevant.
When I was running my company, my engineers joked that if it were invented
after 1980 I wouldn't let them use it. Which wasn't true, we used mmap().
But the underlying sentiment sort of was true. Even though they were
all used to bash, I tried very hard to not use bash specific stuff.
And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS,
Solaris, Tru64, Linux on every architecture from tin to IBM mainframes,
Windows, Macos on PPC and x86, etc. And probably a bunch of other
platforms I've forgotten.
*Every* time they used some bash-ism, it bit us in the ass. I kept
telling them "our build environment is not our deployment environment".
We had a bunch of /bin/sh stuff that we shipped so we had to go for
the common denominator.
I did relax things to allow GNU Make, there were some features that they
really wanted and that is build environment, so, shrug.
At Sun, 16 Jun 2024 15:48:15 +1000, Alexis
<flexibeast(a)gmail.com>
wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
philosophy' The Register
i feel this comment is unfair.
The specific thing i wrote was:
Here's an excerpt from something i wrote
on the Gentoo forum back in April:
> [[...]] the situation on
> Linux was a mess. Many of the (usually
> volunteers) who maintain packages for
> Linux don't want to have to learn the
> complexities of shell scripting and the
> subtle issues that can arise
That pretty much says it all about the state of the GNU/linux world
right there.
In the "Unix world" everyone learns shell scripting, some better than
others of course, and some hate it at the same time too, but I would
say
from my experience it's a given. You either learn shell scripting or
you are "just a user" (even if you also write application code). the _complexities_ of shell scripting and the
_subtle issues_ that can
arise
[emphasis added]
The issue isn't about learning shell scripting _per se_. It's about the
extent to which _volunteers_ have to go beyond the _basics_ of shell
scripting to learn about the _complexities_ and _subtle issues_ involved in
using it to provide _robust_ service management. Including learning, for
example, that certain functionality one takes for granted in a given shell
isn't actually POSIX, and can't be assumed to be present in the shell one is
working with (not to mention that POSIX-compatibility might need to be
actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT).