What's New in POSIX 2024

Oh my god. This makes me so happy. This is the most lovely think I've read in the world of computing since the unix gods decided that newlines were to be a single character.

The philosophy underlying the sentence "Wouldn’t it be nice if the naive scripts were just correct now?" is incredibly positive. We are surrounded by arrogant jerks who break old code by aggressively enforcing stricter compliance of some stupid rules. But here come these posix heros who do the exact opposite: make old code correct! There is hope in mankind after all.

  - find(1p) now supports -print0
  - xargs(1p) now supports the -0 argument
  - newlines in filenames now should throw errors in many utilities
  - a complier implementing the c17 standard is now required
  - ulimit is expanded
  - renice can use relative values
  - a timeout utility has been added
  - make adds support for $^ $+ ::= :::= != ?= +=
  - logger is improved
  - gettext is adopted
  - readlink and realpath are adopted
  - rm now supports -d to remove empty directories and -v for verbose
  - various improvements to printf, sed, test

Finally. Now let's do the rest: https://dwheeler.com/essays/fixing-unix-linux-filenames.html

Filenames should be boring printable normalized UTF-8. I have never, not once, seen a good reason that a filename should be able to contain random binary gobbledygook

    SRC != ls *.c

> Applications shall select target names from the set of characters consisting solely of slashes, hyphens, periods, underscores, digits, and alphabetics from the portable character set

… makes PowerShell start to look damn good.

The way I feel posix, and other descriptive standards work best is when they describe what every one is already doing. This is opposed to prescriptive standards which try focus on how the "correct" way to do somthing, prescriptive standards tend to be over engineered and may or may not actually work.

see also: descriptive and prescriptive dictionaries. http://www.englishplus.com/news/news1100.htm

For shell scripts part of a large system, that's probably fine. For small scripts, that's not very practical. You are not only adding a compilation step, you're also requiring distribution of multiple files. That's a pain.

It just kind of kills the convenience of a simple shell script. I would probably end up writing a makefile to manage all of this and at that point I am only a hop skip and jump away from using a compiled language instead of shell.

But restricting this at syscall level is definite insanity, among with excuses.

Is this really good?

If you can't rely on anything concrete being guaranteed, and it is open to interpretation what "modern" or "major toolchains" are, why have a standard?

(Listed in the Sortix article linked in OP.)

Pathnames can neither contain NUL nor '/'.

Re: `find -print0` / `xargs -0`:

> Previous POSIX releases have considered -print0 before, but never ended up adopting it because using a null terminator meant that any utility that would need to process that output would need to have a new option to parse that type of output.

What nonsense. Just add the `-0` or similar options as needed.

> More precisely, this approach does not resolve our original problem. xargs(1p) can’t sort, and therefore we still have to handle that logic separately, unless sort(1p) also grows this support, even after read(1p). This problem continues with every other type of use-case. Importantly, it breaks the interoperability that POSIX was made to uphold.

More nonsense.

> A bunch of C functions3 are now encouraged to report EILSEQ if the last component of a pathname to a file they are to create contains a newline (put differently, they’re to error out instead of creating a filename that contains a newline).

Ok, that's tolerable. Ditto utilities (notice here they were able to make a list of utilities).

I wish it would have been c99. What does c17 add exactly, more C++-esque complexity or not? Why was it not c99 (or perhaps even c11) over c17? Genuine questions.