On 14/10/2026 00:22, G. Branden Robinson wrote:
[please CC me on replies]
Hi folks,
I noticed the following commit.
commit 700d8235a391fdc8aa0fcdcf58ebc22bc6800ef0
Author: Pádraig Brady <[email protected]>
AuthorDate: Sat Oct 10 11:33:58 2026 +0100
Commit: Pádraig Brady <[email protected]>
CommitDate: Sat Oct 10 21:02:48 2026 +0100
all: only markup --help when outputting to tty
Since v9.10 (Feb 2026) --help always outputs bold and hyperlinks
even when output was not a tty, as this was thought more useful
with pagers and grep etc. This change makes the more conservative
choice of only outputting markup to tty so that users who do not
have less setup to display color (-R), or users who enable color
by default in grep, get improved output (though without URLs etc.)
* src/system.h (oputs_): Call isatty() when not
forcing markup with $IN_HELP2MAN. Also reverse the
double negatives to a more natural form.
* man/local.mk: Remove redundant assignment of $TERM.
* doc/coreutils.texi (common options): Mention that --help markup
requires output to be a tty, and that $IN_HELP2MAN overrides that.
* NEWS: Mention the change in behavior.
I recommend reverting it, or at least dropping the `isatty()` condition
such that whatever you would send to a terminal device, you submit to a
pipeline.
Two reasons I recommend that are:
1. a lengthy philosophical musing on the design of the Unix terminal
interface and how the decision to prepare output differently
depending on isatty(3), perhaps pioneered by GNU fileutils 30 years
ago or longer, was mistaken;[1] and
2. GNU less(1) is expected default to `-R` behavior in v712 anyway.[2]
I gather this matter has led to much gnashing of teeth by people who
want their pipelines scrubbed of terminal/Teletype escape sequences.
Assuming that the coreutils developers take my advice, I invite such
people to come argue with me about this on the groff at gnu list rather
than here.
Regards,
Branden
[1] First, if the isatty(3) camp's premises are correct, ask yourself
why the utilities col(1), ul(1), and colcrt(1) existed.
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/col.1
https://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/man/man1/ul.1
https://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/man/man1/colcrt.1
If you want the lengthy philosophical musing, here it is.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312935#19
[2]
https://github.com/gwsw/less/commit/5ee3ca4d52db313df7a68c4e0420157d2887e31e
Yes I agree with you, but it's one of those awkward borderline cases.
Given the new less(1) default is not yet generally distributed,
the more conservative approach is a bit safer,
albeit a degraded experience for most.
Given --help output is for human rather than programmatic consumption,
I intend to reconsider this in future
when the newer less(1) is more generally available.
cheers,
Padraig.
