20 Jun
2024
20 Jun
'24
8:14 p.m.
On Sun, Jun 16, 2024 at 06:25:31PM -0700, Larry McVoy wrote:
On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis
wrote:
My latest brush with someone using bash in the wrong place was when
I saw the configure scripts for GlusterFS break on NetBSD. Because
someone had used bash 4 syntax in the configure scripts ... presumably
on a Linux variant where /bin/sh == /bin/bash. While that was easy to
fix (and the PR accepted and patched in) I shouldn't have had to fix
that in the first place ...
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
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).
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.