Skip to content

fix(assert): say what assert_contains_ignore_case actually folds - #1361

Merged
Chemaclass merged 1 commit into
mainfrom
fix/1351-ignore-case-ascii-only
Sep 9, 2026
Merged

fix(assert): say what assert_contains_ignore_case actually folds#1361
Chemaclass merged 1 commit into
mainfrom
fix/1351-ignore-case-ascii-only

Conversation

@Chemaclass

Copy link
Copy Markdown
Member

🤔 Background

Related #1351

A comment claimed both implementations fold non-ASCII identically in a UTF-8 locale, and used that to rule out a pure-bash A-Z fold for the Bash 3.0 fallback. Measured on ÑÜ: BSD tr folds it, GNU and busybox tr do not, and nocasematch folds it under UTF-8 but not under LC_ALL=C. The Bash 3.0 job runs on Debian, so the difference is in CI.

💡 Changes

  • State the guarantee as ASCII-only — in the docs, and in the comment with the measurements that replace the wrong claim.
  • Pin it with a test that runs on both implementations: the Bash 3.0 job takes the tr branch, every other job the nocasematch one. Non-ASCII is deliberately left unasserted rather than pinned to whichever platform the test happens to run on.
  • No behaviour change. Regenerated the bashunit doc snapshot for the doc line.
  • Follow-up worth its own issue: with the claim corrected, the pure-bash ASCII fold the comment ruled out is viable again, and would take two tr forks off the Bash 3.0 path.

https://claude.ai/code/session_01EXYWTGLjf7qM8Ru3GakDRm

A comment claimed the two implementations fold non-ASCII identically in
a UTF-8 locale, and used that to rule out a pure-bash A-Z fold for the
Bash 3.0 fallback. Measured on `ÑÜ`:

  BSD tr (macOS)        folds      -> ñü
  GNU tr (Debian)       does not   -> ÑÜ
  busybox tr            does not   -> ÑÜ
  nocasematch, UTF-8    folds      -> matches
  nocasematch, LC_ALL=C does not   -> no match

So the branches disagree wherever tr is not BSD, and the fast path
disagrees with itself across locales. The Bash 3.0 job runs on Debian,
so the difference is in CI, not hypothetical.

ASCII folding is the only portable guarantee, so that is what the
assertion promises now: stated in the docs, in the comment with the
measurements, and pinned by a test that runs on both implementations --
the Bash 3.0 job takes the tr branch, every other job the fast one.
Non-ASCII is deliberately left unasserted rather than pinned to
whichever platform the test happens to run on.

No behaviour change. The wider point is worth keeping: `tr` is not one
implementation, and any claim that a pure-bash construct and an external
tool agree needs BSD, GNU and busybox, not just a developer's Mac.

Closes #1351

Claude-Session: https://claude.ai/code/session_01EXYWTGLjf7qM8Ru3GakDRm
@Chemaclass Chemaclass added the bug Something isn't working label Sep 9, 2026
@Chemaclass Chemaclass self-assigned this Sep 9, 2026
@Chemaclass
Chemaclass merged commit d0f252b into main Sep 9, 2026
37 checks passed
@Chemaclass
Chemaclass deleted the fix/1351-ignore-case-ascii-only branch September 9, 2026 09:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant