POSIXLY_CORRECT is ignored for option parsing: options after operands are still parsed

Summary

GNU getopt stops option processing at the first non-option argument when POSIXLY_CORRECT is set in the environment, everything after the first operand is treated as an operand. This is documented in the coreutils manual "Common options": "if the POSIXLY_CORRECT environment variable is set, options must appear before operands" and in getopt(3).

uutils utilities (clap-based parsing) ignore POSIXLY_CORRECT here and keep permuting options and operands. This affects all clap-parsed utilities, not just rm. rm is just the case where the difference is most consequential.

Details

POSIXLY_CORRECT is currently only consulted for utility-specific semantics (block sizes in df/du, echo escapes, wc, pwd, ls, ...), not for argument ordering.

Not affected: basename, seq, tr (stop after operands anyway); echo, expr, test, true, false (no getopt options); env, nice, nohup, stdbuf (always stop at the first operand); stty (own parser). join and pr are excluded because GNU itself does not honor POSIXLY_CORRECT there.

PoC

Reproduced on the 0.11.0 release and on current main (c7b4ee8, 2026-09-01)

$ mkdir -p test/dir/sub; touch test/dir/a test/dir/sub/b
$ POSIXLY_CORRECT=1 rm test -rf    # (GNU coreutils) 9.7
rm: cannot remove 'test': Is a directory
rm: cannot remove '-rf': No such file or directory
$ echo $?
1
$ ls -d test
test

$ POSIXLY_CORRECT=1 coreutils rm test -rf
$ echo $?; ls -d test
0
ls: cannot access 'test': No such file or directory

$ POSIXLY_CORRECT=1 ls . -l
GNU: ls: cannot access '-l': No such file or directory, followed by compact listing of .
uutils: long listing of '.'

$ echo "data" > x ; POSIXLY_CORRECT=1 cat x -n
GNU: cat: -n: No such file or directory
uutils: prints x with line numbers