FreeBSD and macOS tr take -u to guarantee that output is unbuffered,
and scripts written for them use it to pass progress output through a
pipeline as it arrives, e.g. `curl ... 2>&1 | tr -u '\r' '\n'`. uutils
tr rejected the option, so such pipelines failed outright.
On Unix every chunk is already written as soon as it is translated, so
-u has nothing left to do there. Windows still writes through the line
buffered Stdout, so flush it after every chunk when -u is given.
Record what the LTO mismatch cost and why the existing function-count check
does not catch it, and add measured per-utility gains to the performance page.
The page promised a report at a terminal without saying that one is only
drawn when the error can be tied to an argument: an error about no single
argument, or an operand rewritten before it could be located, still falls
back to the plain one-line message. Record that, and that a usage error
keeps its "Try --help" hint under the report.
Handle cut's short-only -F mode explicitly and preserve head's original
argv before obsolete option rewriting. Add regression coverage and document
-F among the supported cut modes.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The summary already listed this page, but the page itself lived on a
branch of its own, so the link went nowhere. Bring it here, next to the
code it describes, and bring it up to date: env, cut, head, tail and
truncate have carets now, the three shared parsers each explain their
own syntax for every utility that uses them, and a caret can point
inside an argument that had to be echoed back quoted.