What's New in POSIX 2024

Original Article ↗ Hacker News Discussion ↗

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.