To POSIX or not to POSIX: Where to draw the line?
Created by: ksf
Essentially, I think that there are two reasons to use POSIX as a reference:
- Because people are used to it. That is, to simplify, Redox shouldn't be an OS in which you type
ls
and get acommand not found
. - For compatibility. That is, a C99 program with a Makefile and some
/bin/sh
scripts should readily compile and run.
These two considerations, I'd like to argue, are completely distinct and should be dealt with, and solved, in completely different ways:
For user interaction, POSIX shows its age. It's a spec that basically contains anything any oldish UNIX ever did, which often was not very well-advised. There's a lot of legacy cruft, yet also a majority of brilliant things. One project which I think gets the balance between "keep things looking like POSIX" and "do away with all the borkage" just right is fish
: It kind of feels like the bourne shell, but unlike say bash
or zsh
it actually is incompatible and makes very sane choices such as using plain parenthesis to launch sub-shells: ls -l (which whoami)
. Contrast with bash, which supports the plain old backtick syntax with all the trouble that brings when nesting, as well as $(which whoami)
.
That is, it keeps the good and accustomed to while having no qualms breaking backwards compatibility and doing things right instead of being cruft-compatible. But fear not, I'm not arguing to give up compatibility!
On the source compatibility side we have different issues. We have people using #!/bin/sh
and expecting it to be bash
(until they see Debian), we have people using GNUisms all over the place and failing on BSD or the other way around, and all that has a simple reason: There's literally no system which is POSIX, and only POSIX, and POSIX only, there's not a single environment that would force you to stick to the shared subset because, and this isn't surprising, everyone wants to add their own bells and whistles.
Thus, I propose two different environment for Redox: One, where we go the fish
way and e.g. just use ripgrep
and call it grep
. The other is a posix-me-harder environment in which there's not a single program that has a command line flag not in the specs, and in which every single other dependency has to be specified explicitly: If you want bashisms that's fine, but then use #!/usr/bin/env bash
, because it's not going to be in either /bin
or $PATH
. Enforce portability, hard. People are going to groan but they're going to accept it because if you got something running in this environment, it does indeed run everywhere.
Thoughts?