On 09/10/2026 08:13, Eli Schwartz wrote:
On 10/9/26 12:30 AM, Collin Funk wrote:

The rationale for including the links when piped or redirected was so
that you could use the links when piping into 'less', for example.

I'm leaving this report open for now, since I think we may want to
reconsider this due to this report and one or two similar ones.
Unfortunately, I am unable to link them since I haven't been able to
connect to bugs.gnu.org for the past week, except for a few hours
yesterday. :(


Similar logic applies to color; I personally rather like LESS="-R" and
viewing logfiles in color, but many people distinctly dislike it.

And that is why ls (and many other programs) has --color=WHEN, and
specifying auto / letting it default to such, will do isatty detection.
I admit it seems a bit convoluted to expect users to run

chroot --color=never --help

to disable bold/underline/links in help text, but I think the underlying
principle is the same and I don't really know that I understand the
rationale for assuming by default that it will be read by less or, more
pertinently, that users have configured less to get [readable] output

IMHO less(1) should enable -R by default.
Does anyone want less(1) to not show colors for example?
I.e. if you leave less(1) with default settings, this also messes up:

  ls --color | less

But fair enough we should work on getting less to change its default
before trying to force the situation.
Meanwhile, in a terminal that supports them, I can normally click on ls
--help's hyperlinks, but piping it to less -R actually breaks that, and
I don't know whether it's supposed to work (or how), so the feature
simply has my heartiest shrugs.
`ls --help | less -R` should work.
What version of less are you using?

cheers,
Padraig



Reply via email to