What's New in POSIX 2024

Original Article ↗ Hacker News Discussion ↗

A major update to the POSIX standard for Unix-like systems introduces features such as `set -o pipefail`, `find -print0`/`xargs -0`, a standardized `timeout` utility, and a move to requiring C17 compilers. Commenters welcome steps that make shell scripting safer and more predictable—like treating newlines in filenames as errors—while arguing over how far standards should go in restricting filenames, enforcing UTF‑8, and cleaning up long-standing shell pitfalls. The broader tension is between POSIX as a descriptive record of existing practice versus a prescriptive force for modernization, and what that balance means for portability, security, and the future of alternative shells.

Newlines and “sane” filenames

  • Strong support for treating newlines in pathnames as errors in POSIX utilities, mainly to protect naive, line-based scripts and mitigate terminal-escape attacks via filenames.
  • Others argue this is only a partial, “feel-good” measure: POSIX can’t change existing filesystems, filenames with newlines still exist, and robust scripts must still handle them.
  • Concerns about breaking existing workflows (e.g., programmatically generated filenames or academic PDFs with multi-line titles).
  • Broader wishlist: options or mount flags to enforce “sane” filenames (UTF‑8 only, no control chars, maybe even no spaces), but pushback that filesystem-level hacks to compensate for bad shell scripts are a bad tradeoff.

Shell pitfalls, pipefail, and error handling

  • set -o pipefail being standardized is widely welcomed; it makes entire pipelines fail when any component fails.
  • Some claim it’s often misused and, combined with set -e, leads to hard-to-debug silent exits. Others argue it’s valuable when used with explicit error handling instead of “shotgun” set -e.
  • set -u (treat unset variables as errors) is seen as mostly good; set -e is considered dangerous unless confined to small regions.
  • More general complaint: POSIX shell semantics around word splitting, arrays-as-strings, and filenames with whitespace/newlines are considered extremely error-prone; defenders counter that it’s small, ubiquitous, and well-suited to quick automation if you understand the rules.

Text vs structured data (JSON, UTF‑8, objects)

  • One camp wants to standardize on UTF‑8 and JSON (or JSONL) as the universal interchange format and build shells around structured data, citing PowerShell and nushell-like designs.
  • Opponents argue Unix text pipelines are foundational, JSON’s spec and streaming properties are imperfect, and CLI output is primarily for humans. They prefer incremental additions (e.g., -print0/-0) over a format revolution.

Standards role and evolution (POSIX & C)

  • Debate over descriptive vs prescriptive standards: some say POSIX should describe existing practice; others say it must prescribe better behavior to avoid obsolescence.
  • POSIX 2024’s move to require C17 is discussed: C17 is essentially C11 with bugfixes and a proper memory model (atomics, TLS errno, _Generic, _Static_assert, etc.).
  • Future plan to require “the most modern C implemented by major toolchains” is criticized as vague, but seen as pragmatic by some.