Hacker News Reader

Comment by mkdirp | Hacker News Reader

> Ideally, the function is POSIX-compatible, so it runs on the widest number of platforms.

But... Why? During my professional career of about 10 years, and even before that, I've not once had to require POSIX compatibility for any of the shell scripts I've written or come across. The few times I had a snippet that couldn't run I have been able to install bash 4+ with ease.

I'm sure there are times where POSIX is kind of needed, but it's becoming exceedingly rare.

View on HN

The Linux monoculture in internet services does reduce the value of POSIX-compliance.

I got in the habit of at least gesturing towards POSIX back when it was more common to run a bunch of different unixes. And I still run both FreeBSD and Linux at home, so there's value there for me.

Mostly, I still do it because I'm always surprised by which artifacts I create end up being long-lived, and you never know what will be valuable in the future. One of the things I'm technically proudest of ended up only being useful for less than a year, whereas I know a dumb 4 line hack I wrote on a contract in 2002 is still running via cron every night, now on a VM in AWS.

I think it would be helpful if we can update the POSIX shell standard. This is the only way that the Debian/Ubuntu /bin/sh will ever change.

Microsoft was pivotal in the formation of the standard, as Korn was required to run in a 64k text segment for Xenix, and this was retained for POSIX.2.

The parser for the Borne family is very complex, and cannot be implemented with a yacc grammar. There is some value in starting again with something less convoluted.

This guy tried to implement a POSIX shell in OCaml, and he is rather perturbed with the entire Borne family (I wish I knew parsers this well):

https://m.youtube.com/watch?v=fiJR4_059HA

Bash has a number of real strikes against it... GPLv3 - which caused Apple to dump it, speed - which caused Debian/Ubuntu to demote it, and the lingering damage bashisms and their damage to portability.

This discussion of a high-performance POSIX shell for Windows is also enlightening.

https://video.fosdem.org/2019/AW1.125/ada_shell.webm

I can't think of any time where I have needed the same script to run on multiple systems, because that's not the sort of thing I use shell scripts for. But there are many times where I have needed to write a script for a specific system that was running busybox or dash or ksh, and it is worth knowing what features I can use in those cases.

But then your source is probably not something called “Pure Bash Bible”.

I have a Korn shell script that I use to run SQL against a few dozen databases.

I recently rewrote this script, so it would run on Windows, via Busybox ash. It needed quite a few changes. I've become somewhat practiced on the removal of bashisms.

Oddly enough I had to put a few back. Busybox on Windows doesn't implement stty that I needed to read a password, but it did have read -s, so I used that instead. I threw several snippets of ash-emulated bash back in, that would never ever run on dash.

When you ask "but why?" this is precisely why - I need this functionality in a specific place, where you cannot go.

Reply on news.ycombinator.com