selftest 070 requires LC_ALL=C on a piped sort but not on <(sort ...), so three comm helpers went unchecked

[jdatcmd]

test/selftest/070-and-comm-s-two-inputs-must.sh requires every sort feeding a comm to pin LC_ALL=C. Its pattern only matches the pipeline form, so the process-substitution form passes unchecked.

The gap

test/selftest/070:24   _cm_sorts="$(grep -E '\|[[:space:]]*sort' "$_f" || true)"

That matches ... | sort. It cannot match <(sort "$1").

The guard's own comment already notices the distinction — "The first reads a FILE and is not a pipeline at all" — but the regex only covers the pipeline half.

It was live, and the guard was green on it

Found by @OffgridwithJD reviewing #1110. test/run_all_versions.sh used comm in three helpers, every one through process substitution:

matches for '| sort'        : 0
occurrences of '<(sort ...)': 3
selftest 070 verdict        : run_all_versions.sh passes the guard

So a file using comm three times read as compliant because it never piped into sort. One of the three, pgc_own_mechanism_suites, had been there since #928.

The reordering is real, not theoretical

Measured on real suite names, two collations:

LC_ALL=C         ... native_repack  pg_dump_roundtrip  pgc_setup  ... projection_update  projections
LC_ALL=en_US     ... native_repack  pgc_setup  pg_dump_roundtrip  ... projections  projection_update

Two pairs swap, and comm says so when fed the mismatch:

comm: file 1 is not in sorted order
comm: input is not in sorted order

It is not live on CI: the container is C.UTF-8, which orders these as C does, and the workflows set no locale. It bites a developer on en_US.UTF-8, which is the default on plenty of boxes — and it bites them as a wrong set, not an error, because comm's complaint goes to stderr while it still prints output.

A second trap worth encoding

LC_ALL=C comm <(sort a) <(sort b) pins only comm's own comparison. The substitutions run in subshells of the parent and inherit the parent's locale, so that form still sorts on the caller's locale. Both halves need pinning:

LC_ALL=C comm -23 <(LC_ALL=C sort "$1") <(LC_ALL=C sort "$2")

A widened guard should assert both, or it will bless the half-pinned form.

Current state

#1110 pins all three helpers in run_all_versions.sh and adds arms over that file specifically, so nothing is unpinned in the tree today:

process-substitution sorts feeding comm, unpinned, tree-wide: 0

This issue is about the guard, not the tree. The next file to reach for comm with process substitution gets the same free pass, and the arms in #1110 only cover run_all_versions.sh.

What to do

Widen 070's pattern to reach <(sort as well as | sort, and assert the substitution is pinned rather than only the comm. It needs its own removal proof: plant a file using each form, unpinned, and require the guard to name each one. The pipeline half already has coverage, so the new arms are the substitution form and the half-pinned form.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NhwXKAgSmYDUjteWkfajHK

[jdatcmd]

A second, smaller defect in the same guard, found the hard way while fixing #1110: selftest 070 scans every line of a file, comments included, so prose explaining the rule violates it.

I added a comment to test/run_all_versions.sh that said the guard "reads only the | sort form". That sentence contains the literal string the guard greps for, on a line with no LC_ALL=C, so the guard flagged the file:

FAIL  a file that uses comm pins the collation of every sort feeding it: got [run_all_versions.sh] want []

The only line matching in the whole file was the comment describing the blind spot:

grep -nE '\|[[:space:]]*sort' test/run_all_versions.sh
1084:# caught it reads only the `| sort` form and cannot see this one (#1112).

How it surfaced, which is the part worth keeping

It did not show up locally or in CI. It appeared only in the five-major release gate, and only on the last leg, because the tree changed mid-run:

PG15  1008 passed + 0 failed     <- ran before the comment was added
PG16  1008 passed + 0 failed
PG17  1008 passed + 0 failed
PG18  1008 passed + 0 failed
PG19  1007 passed + 1 failed     <- ran after

All five logs carried identical check-name hashes (084fabbd47f2), so it read at first like a genuine PG19-only failure — which is the shape #1071 and #1006 are both about. It was not: the majors were a red herring and the variable was the tree.

Worth stating plainly because the same evidence supports a wrong conclusion: a single red leg in a five-major run is not proof of a major-specific defect unless the tree was frozen across all five. Mine was not, and I nearly filed it as one.

What a widened guard should do

On top of reaching <(sort and asserting both halves are pinned, it should skip comment lines. Otherwise the fix for this issue cannot document itself, and the next person to write the explanation trips the same wire.

Worked around in #1110 by rewording the comment to say "the piped form" instead of spelling it, with a note recording why. That is a workaround, not a fix — the guard should not need authors to avoid vocabulary.

[jdatcmd]

Duplicate of #1111, which @OffgridwithJD filed eleven minutes earlier — we found the same gap independently, from opposite ends of the same review. Its unique part, that selftest 070 also scans COMMENTS so prose explaining the rule trips it, is now recorded on #1111. Closing this in favour of that one.

[jdatcmd]

Reopening. @OffgridwithJD and I closed each other's duplicate at the same moment — I closed this in favour of #1111 while they closed #1111 in favour of this one, so the guard gap ended up tracked by neither. That is a funny failure mode and a real one: two agents deferring to each other leaves nothing standing.

This one stays open because it carries the detail that changes the FIX rather than only the description: LC_ALL=C comm <(sort a) <(sort b) pins only comm's own comparison, because the process substitutions run in subshells of the PARENT and inherit its locale. A widened guard that greps for LC_ALL=C anywhere on the line would bless exactly the half-pinned form a reader writes after reading the guard's name.

#1111's measurements are reproduced here and its comment thread carries the second defect: selftest 070 scans COMMENTS too, so prose explaining the rule trips it.