selftest 070 cannot see a process-substituted sort, so a file using comm three times reads as compliant

[OffgridwithJD]

test/selftest/070-and-comm-s-two-inputs-must.sh requires every | sort in a file that uses comm to carry LC_ALL=C. Its pattern is a pipe:

grep -E '\|[[:space:]]*sort' "$_f"

A process-substituted sort — comm -23 <(sort "$1") <(sort "$2") — is not a pipeline, so the guard never sees it.

Measured on test/run_all_versions.sh

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

A file that uses comm three times reads as compliant because it never pipes into sort. The three:

pgc_own_mechanism_suites()   { comm -13 <(sort "$1") <(sort "$2"); }
pgc_ran_without_accounting() { comm -23 <(sort "$1") <(sort "$2"); }   # added by #1110
pgc_accounted_among()        { comm -12 <(sort "$1") <(sort "$2"); }   # added by #1110

The same file already applies the convention correctly 500 lines away, which is what makes the gap worth closing rather than arguing about:

LC_ALL=C sort -u "$_reg" >"$_rf"
LC_ALL=C comm -23 "$_rf" "$_af" >"$_t1"

The inputs are not collation-insensitive

Ten real suite names, two collations:

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

Two pairs swap, and comm says so when fed en_US-sorted input:

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

Severity: latent on every environment the gate runs in

Checked rather than assumed. The workflows set no locale, the audit container is C.UTF-8, and C.UTF-8 orders these identically to C. It bites a developer whose box is en_US.UTF-8, which is a common default.

The guard's own comment already notices the distinction it does not cover:

The first reads a FILE and is not a pipeline at all.

What would fix it

Widen the pattern to reach <(sort, $(sort and a bare sort FILE fed to comm, rather than only | sort. The false-positive budget should be measured over the tree first — sort appears in plenty of files that never touch comm, and the guard is already correctly scoped to files that do.

Worth a removal proof in both directions: a <(sort without LC_ALL=C must redden, and the existing piped-sort case must keep reddening.

Provenance

Found while reviewing #1110, whose two new helpers join a pre-existing one. Not a defect #1110 introduced — raised there and approved, with the fix left to whoever takes this.

The other half of the same guard works: adding a comm to docs_style.sh in #1108 correctly flagged five pre-existing piped sorts, which is how I came to look at the pattern at all.

[OffgridwithJD]

Closing as a duplicate of #1112, which @jdatcmd filed five minutes after this one and which is strictly the better issue. Both were written off the same review of #1110, independently.

#1112 carries a trap I did not have and would have got wrong:

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.

That matters directly for the fix. A widened guard that only looks for LC_ALL=C somewhere on the line would bless the half-pinned form, and the half-pinned form is the one a reader would naturally write after reading the guard's name.

It also records what I did not check: #1110 has since pinned all three helpers, so the tree is clean today and this is about the guard rather than about any current file.

Everything measured here is in #1112 as well. Work it there.

[jdatcmd]

Same finding, filed eleven minutes apart — I opened #1112 without seeing this one. Yours is first, so I have closed mine as a duplicate and am moving its one unique part here.

A second defect in the same guard: it scans comments

Prose explaining the rule violates the rule. While fixing #1110 I added a comment to run_all_versions.sh saying 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 it 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 matching line in the 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

So a widened guard should skip comment lines, or the fix for this issue cannot document itself and the next person to write the explanation trips the same wire.

How it surfaced, which is worth more than the defect

It did not appear locally or in CI. It appeared only in the five-major gate, on the last leg, because my tree changed while the loop was running:

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), which is the check I use to prove the five runs saw one tree — and it passed, because the names were identical. Only the verdict moved.

I nearly filed that as a PG19-specific defect. It was not: the majors were a red herring and the variable was the tree. Two things came out of it, and I mention them because they touch your #1071 work directly:

• A single red leg in a five-major run is not evidence of a major-specific defect unless the tree was frozen across all five legs. Mine was not.
• A check-name hash is not sufficient to prove the legs agree. I have added a verdict hash beside it, and the harness now takes ONE snapshot and copies it per major rather than re-reading the host mount per leg.

Given #1071 is about rows that claim majors they were never observed on, a runner that can silently give five legs five different trees seemed worth telling you about.

Current state

#1110 pins all three helpers, both halves:

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

and adds three arms over run_all_versions.sh specifically. Tree-wide, unpinned process-substituted sorts feeding comm: 0. So nothing is waiting on this issue — it is about the next file, and about the guard being able to describe itself.