4 ms·

> try to restrict shell scripts to POSIX semantics I have to admit, while i admire the idea of and understand the reasoning behind striving for POSIX-compatib

> try to restrict shell scripts to POSIX semantics I have to admit, while i admire the idea of and understand the reasoning behind striving for POSIX-compatibility, i never couldn't fully get past viewing this as some kind of hypothetical exercise. The chance that any script i (or presumably most people who get this advice on pages like SO) will ever write will have to run on a 25 years old Tru64 machine or even a modern Mac, BSD, QNX, … is relatively small. Truth is (in my case), most of the scripts will never even run on anything but the system they were written on. As i said, i admire the idealism though.

0xbadcafebee 4y ago
Many people who write in Bash end up writing in Bash v4, which won't work on a Mac until you install bash from Homebrew. Whereas POSIX just works. If you need to run a script on an Alpine Linux container and didn't install bash, that would be using ash, so again POSIX would work. But the reason to use POSIX scripting isn't portability, it's simplicity. Simple scripts are just easier to reason about, easier to maintain, and are less prone to bugs. The code might be a little more verbose, but its simplicity still reduces the cost of complexity. Most people don't realize this until they've been writing scripts for 15 years and realize they can do almost everything with POSIX and that it makes their life easier in the long run. But in some cases what I want to do would really benefit from Bash, so I use Bash then. It's not a hard and fast rule; I switch based on what would work best for that case. It's about balance, compromise, and being flexible.
alganet 4y ago
It is easier than you think. First, we get rid of PATH= inside scripts. A lot of incompatibilites comes from /bin, not the shell itself. Treat executables like services, rewrite everything (reasonable) in pure shell. The scenario I'm trying to prevent is "I want to cut a string in OSX but I wrote for a GNU executable and the syntax is slightly different". Most shell one liners can be rewritten as good quality portable code. If you take just Debian, there are 5 or 6 shells available via apt. These should run wherever Debian runs (x86, arm, hurd, whatever). You can't write a reasonable JavaScript that runs on JScript.exe (it still exists), Apple JXA, gjs and node.js. But you _could_, the language is stable enough, for long enough, that everyone knows how to feature detect the shit out of everything js related. For the shell though, we don't even have a solid list of things that work or not in each shell, or differences across core utilities. Something like caniuse.com, but for UNIX shells, not browsers. Having a page that runs on all browsers was once something impractical and idealistic. Not using tables and invisible 1x1 pixels for layouts was once idealistic. We fixed it though. Mostly.
SAI_Peregrinus 4y ago
Many of my scripts run on my computer, but also have to run on Alpine Linux because that's what my employer's CI system exposes. That means Busybox for the common shell utilities (unless the script or job installs something else as needed) and thus POSIX compatibility is important.

0xbadcafebee 4y ago

Many people who write in Bash end up writing in Bash v4, which won't work on a Mac until you install bash from Homebrew. Whereas POSIX just works. If you need to run a script on an Alpine Linux container and didn't install bash, that would be using ash, so again POSIX would work. But the reason to use POSIX scripting isn't portability, it's simplicity. Simple scripts are just easier to reason about, easier to maintain, and are less prone to bugs. The code might be a little more verbose, but its simplicity still reduces the cost of complexity. Most people don't realize this until they've been writing scripts for 15 years and realize they can do almost everything with POSIX and that it makes their life easier in the long run. But in some cases what I want to do would really benefit from Bash, so I use Bash then. It's not a hard and fast rule; I switch based on what would work best for that case. It's about balance, compromise, and being flexible.

alganet 4y ago

It is easier than you think. First, we get rid of PATH= inside scripts. A lot of incompatibilites comes from /bin, not the shell itself. Treat executables like services, rewrite everything (reasonable) in pure shell. The scenario I'm trying to prevent is "I want to cut a string in OSX but I wrote for a GNU executable and the syntax is slightly different". Most shell one liners can be rewritten as good quality portable code. If you take just Debian, there are 5 or 6 shells available via apt. These should run wherever Debian runs (x86, arm, hurd, whatever). You can't write a reasonable JavaScript that runs on JScript.exe (it still exists), Apple JXA, gjs and node.js. But you _could_, the language is stable enough, for long enough, that everyone knows how to feature detect the shit out of everything js related. For the shell though, we don't even have a solid list of things that work or not in each shell, or differences across core utilities. Something like caniuse.com, but for UNIX shells, not browsers. Having a page that runs on all browsers was once something impractical and idealistic. Not using tables and invisible 1x1 pixels for layouts was once idealistic. We fixed it though. Mostly.

SAI_Peregrinus 4y ago

Many of my scripts run on my computer, but also have to run on Alpine Linux because that's what my employer's CI system exposes. That means Busybox for the common shell utilities (unless the script or job installs something else as needed) and thus POSIX compatibility is important.