Shell In 2025, do you still need to follow the POSIX standard in shell scripts? / What is your shell for scripting?

Shell scripts for anything longer than 100 lines is mostly always wrong. I may use POSIX shell depending on context but in most cases I'd just use Bash because of its support for lists and associative arrays. Otherwise use real languages like Perl or Python for scripting.
 
If I think that there is even remote possibility that script will be of use to anyone else, only #!/bin/sh, and if I’m certain that no one else will ever see it I could go for #!/usr/bin/env bash, just for arrays.
 
Git for Windows includes Bash and sh; I chose sh because of FreeBSD and it worked with the same syntax with sed as bare-metal FeeBSD! (sed was wild enough on Linux that years ago I found something that happened to work and stuck with it for years :p)
 
Coming from Linux, I used to use bash. But since I've been using BSD (FreeBSD and OpenBSD) more often for a while now and I don't want to have to install bash on every system, I preferred to adapt my scripts. Your answers confirm the usefulness of still following the POSIX standard, so I think I made the right choice. Thank you for your answers!
 
yes, real shell scripts are for /bin/sh and don't make assumptions about filesystem hierarchy or weird stuff like procfs or fdescfs (but usually those are scripts by linux-kiddies and written for bash anyways...)

And awk is still the prime language for bashing large amounts of (more or less) structured text. It easily beats the crap out of graphical toys like excel/calc in terms of efficiency and speed (heck, excel would choke and burn on most csvs I throw at awk, let alone perform all the transformations/calculations)
 
My preferred shell for scripting is always /bin/sh (not symlink nor hardlink to bash, unlike Linux world), except for configurations for my "interactive" shells, including currently using, used before and possible candidates in the future.

POSIX sh should exist in any POSIX-compliant environments, so limiting with POSIX syntax and functionalities allow maximum compatibility, except "external commands (like sed, awk, cut, ...)".
 
T-Aoki said:
except "external commands (like sed, awk, cut, ...)".
Click to expand...

most standard unix-tools are also part of the POSIX standard, so as long as you only use the standardized parts/options/functionalities of those tools, your script is still perfectly portable. (except of course the OS ships with non-standard variants - i.e. usually all GNU variants which have deliberately dropped POSIX compliance for many tools)
 
sko said:
most standard unix-tools are also part of the POSIX standard, so as long as you only use the standardized parts/options/functionalities of those tools, your script is still perfectly portable. (except of course the OS ships with non-standard variants - i.e. usually all GNU variants which have deliberately dropped POSIX compliance for many tools)
Click to expand...
If I recall correctly, GNU version of tools having extended features are commonly used on Linux distros. Even gcc has GNU extentions...
 
T-Aoki said:
If I recall correctly, GNU version of tools having extended features are commonly used on Linux distros. Even gcc has GNU extentions...
Click to expand...
The extended functionality isn't a problem as long as the POSIX subset is also supported, but some GNU tools have changed or dropped some features specified by POSIX. From my experience, with GNU variants you'd have to *carefully* check the manpage if that tool still offers full POSIX compatibility or that single-letter-option has a completely different meaning on the GNU variant.

Unrelated to POSIX, I more than once had to find that GNU AWK is particularly pesky in changed behavior or syntax for various commands; hence in AWK scripts that I intend to share I usually put the target variant in a comment at the very beginning of the script, i.e. "written for one true AWK/NAWK").
 
sko said:
Unrelated to POSIX, I more than once had to find that GNU AWK is particularly pesky in changed behavior or syntax for various commands; hence in AWK scripts that I intend to share I usually put the target variant in a comment at the very beginning of the script, i.e. "written for one true AWK/NAWK")
Click to expand...
I don't have extensive non-one true AWK/NAWK experience. With the 'release' stemming from the the awk book second edition, however, things might have changed. Also, the FreeBSD's awk(1) has been updated recently :), which is great.
 
sko said:
most standard unix-tools are also part of the POSIX standard, so as long as you only use the standardized parts/options/functionalities of those tools, your script is still perfectly portable. (except of course the OS ships with non-standard variants - i.e. usually all GNU variants which have deliberately dropped POSIX compliance for many tools)
Click to expand...
And yet, if I remember correctly, it was RMS who proposed the name POSIX...
 
kpedersen said:
Between /bin/sh and perl, there is awk. It is actually quite a bit more effective than most people think.

Some example functions.

My general language scale tends to be:

/bin/sh -> Awk -> C/C++
Click to expand...
Aside from the examples I've seen on various forums in response to specific issues, I'm not very familiar with AWK. It's always seemed like a kind of expert language to me...
 
Yog-Sothoth said:
I'm not very familiar with AWK. It's always seemed like a kind of expert language to me...
Click to expand...
I was in the same boat for many years. Based on an O'Rielly book I thought it was only for quick filters alongside sed. But it wasn't until I did a little bit of compiler design at University and linked the A to Aho, author of the Dragon book and K to Kernighan (The C Programming Language). These guys tend to work on some impressive stuff, so I had a deeper look.

Turns out, due to the trend at the time, it is really C-like. Other than fairly poor support for structs and arrays (need to hack around that with associative arrays), it is almost like a scriptable C.

Code: 
function main(_argc, _argv)
{
  print("Hello World!")

  return 0
}

BEGIN { exit(main(ARGC, ARGV)) }

$ awk -f main.awk

Another nice feature is that it *isn't* extensible. If you see an awk script, then it will work rather than needing to drag in a load of crap from CPAN/crates.io/PIP/NPM/etc.
 
You must log in or register to reply here.
Back
Top