On 15/09/2026 23:50, Paul Eggert wrote:
On 9/15/26 16:32, Collin Funk wrote:
Because I thought it was useful that way when piping --help to | less -R
(less is generally configured to use -R by default
since it's a lot more useful like that to display colors etc.)
Doing that also maintains the highlighting.
All true, but it's counterintuitive that "realpath --help | grep foo"
behaves differently from "ls | grep foo". ls disables all the colors and
linking, realpath doesn't.
I suspect this is a case where the benefits of the link are less than
the ability to process the output as text.
One possible way out is for invocations like 'realpath --help' to
automatically pipe their output into 'less' if stdout is a tty. That
would be more convenient than 'realpath --help|less' anyway, and would
solve the problem in a better way.
It that way out isn't feasible for some reason, it might be better for
realpath to do what ls does.
Yes the situation is not perfect, but I'm still leaning towards
this being a better default, as users almost always parse --help directly.
Going with the safest non marked-up output would be a net loss for users IMHO.
I'm also trying to avoid users requiring (new) config if at all possible,
which is why this is gated on TERM=dumb or unset TERM.
In other words, I can't think of where --help would be processed
programmatically
and thus benefit from the removal of the ansi codes.
I don't think this particular grep issue qualifies here as:
- grep doesn't cause an issue by default, and can be easily adjusted to
not output conflicting ansi codes
- grep is not really useful in this case anyway,
due to false positive matches, and descriptions on following lines
- the failure mode is only slightly corrupted output
Outputting to a $PAGER by default is an interesting idea,
though I'm a little worried about compatibility and overkill here.
Note we did release this functionality 7 months ago,
with this being the first (IMHO minor) issue that was reported.
I'll think so more about it.
cheers,
Padraig
