I'd argue that writing scripts for an embedded target for a regular server/workstation target are fundamentally different problems - almost anything I'd write for those platforms would be targeted for them - not for general purpose unix.
Portability is only desirable, if you need portability - otherwise it frequently adds complexity for little return benefit.
Portability is not important in most cases. Most shell scripts are written for and run on a single platform usually as setup or teardown for something else.
Isn't embedded shell scripts exactly what you want though? I can't imagine having the flexibility of configuring entire unix systems without beeing able to ever touch a shell script.
Portability for shell scripts is over rated in 2022.
If your shell scripts are small, it's easy to write several versions of them.
It they are long, you should use something else than shell scripts for your program, like python.
Worse case scenario, provision the same interpretter everywhere, vendor it, or use a compiled language.
There are some edge cases where portability makes sense (e.g: you are scripting for an heterogeneous parc of routers), but they are niche usages most companies don't care about.
Assume the environment you're writing scripts for. Most scripts need only be run on one machine, and thus one platform. Most that don't still run only on one platform. If you need a portable shell script, by all means write one, but that's rarely the case.
Because shell scripts usually have lots of dependencies on external tools, it's harder to make them portable. Those external utilities have different behavior on different platforms. I have much better luck with Python, Perl, etc, for scripts.
Personally I don't write portable shell scripts. They exist only for my own usage on my desktop. If we rely on any kind of script for deployment purposes at work, we use the scripting lang in the build system or a python script
Unless you have an encyclopedic memory and copious leisure time, you'd probably be much better off writing perl scripts instead if you care about portability. There is an enormous amount of sometimes subtle divergence between behaviors of core tools you need for shell scripting (sed, tr, mktemp, readlink all behave very differently between different versions of unix,for example) and even if you manage to memorize exactly what's in posix (and accept the fairly severe limitiations in expressiveness this entails), few things are actually 100% posix conforming.
While it is true that some shell scripts need to be portable, many don't.
Many shell scripts are written just to run in one single machine. Or they run in a controlled environment. Maybe even a docker container that provide anyway a set of tools and dependencies.
Shell scripts are extremely portable and should be the preferred method for a large set of tasks. Properly written, a shell script can run on a 20 year old Solaris machine, any version of Windows (with installed tools like Cygwin) and any modern Unix variant... claiming Node.js is more portable is ridiculous on so many levels.
The problem is so many programmers don't take the time (or care to take the time) to learn to use the well thought out design of Unix tools opting instead to see every problem as a nail corresponding to the latest trend in hammers (programming languages).
This has led a lot of programming types to create advanced tools for managing Unix systems which largely ignore the design of Unix.
Typically shell scripts are fine in the beginning, but over time the complexity rises and it becomes an unmaintanable mess, and you'll end up reimplementing it in a proper programming language.
Shell scripts are not easily portable either, unless by "portable" you mean "works in Linux". Node.js scripts, for example, really (mostly) work on Linux and other platforms like Windows.
Until you hit some nasty "path is longer than 254 characters" bugs. Oh well..
It's minimal effort to maximize compatibility and consistency, regardless of where the script may be run.
Shell scripts can run in a myriad of hosts, from VMs to stripped-down containers. When writing robust production code (not to say that shell scripts are ideal for that purpose), you'll want to minimize moving parts and risk surface, so that you can go home more confident that things will just work regardless of what you throw at it.
I don't understand the downvotes. This is a fair criticism. The author even points out "programs as pipelines" which is literally the UNIX philosophy. There are tools that already exist on UNIX-likes more people should use instead of reaching for a script.
I can sympathize with the author w.r.t wanting to use a single language you like for everything. However, after decades I've found this to be untenable. There are languages that are just simply better for one-off scripting (Perl, Python), and languages that aren't (anything compiled). Trying to bolt an interpreter onto a compiled language from the outside seems like a lot of work for questionable gain.
How do you write a portable shell script? The programs invoked by your shell script need to behave the same everywhere. Even fundamental things like cp, rm, etc. don’t universally behave the same across the various Unix and Unix-like systems.
The joke is that your shell is actually more portable than your shell script :)
Portability is only desirable, if you need portability - otherwise it frequently adds complexity for little return benefit.
reply