"G. Branden Robinson" <[email protected]> writes:
> At 2026-01-21T23:11:48+0000, Pádraig Brady wrote:
>> I was about post that snapshot, and this was actually what stopped me.
>> I am really reluctant to introduce new config into the world,
>> so had an idea to reuse the common TERM=dumb setting,
>> rather than HELP_NO_MARKUP=anything. I can't see why
>> one might want to disable --help markup independently of TERM setting.
>
> Speaking as a contributor to ncurses's man pages, I think that's a good
> idea.
>
> I'm aware of the "NO_COLOR" initative[1], which "*_NO_MARKUP" reminds me
> of, but I don't think it's a great idea because I think it's probably
> not necessary.
>
> For one thing, people who don't want "color" in the output from the
> text-stream oriented programs probably don't want other kinds "graphical
> rendition" styling, like bold or underline or italics, even if these
> aren't changes to "color". Let alone do they want other kinds of
> ECMA-48 escape sequence like OSC, or SOS, or APC, or PM.
>
> To be fair, the "NO_COLOR" initiative, as of this writing, restricts
> itself purely to the suppression of color configuration.
>
> Q. Why not just set $TERM to dumb or xterm without color
> support?
>
> A. ... It is reasonable to configure certain software such as a
> text editor to use color or other ANSI attributes sparingly
> (such as the reverse attribute for a status bar) while still
> desiring that other software not add color unless configured to.
>
> Q. Should the presence of NO_COLOR disable other styling such as
> bold, underline, and italic?
>
> A. No. This standard only signals the user’s intention regarding
> adding ANSI color to text output.
I also dislike adding environment variables for configuration. It is
probably not a controversial opinion on this list. There is a list of
some that is almost certainly non exhaustive [1].
I was considering people who may want colors but not links. Having them
alias 100 programs to "$command --no-markup" seemed unreasonable. With
Pádraig's proposal, though, they would still be able to do the
following:
$ export TERM=dumb
$ ls --color
And there is always '--color=always' which will even write color codes
when redirected or piped.
So, I think the three of us are in agreement here.
I do like NO_COLOR since it is widely supported. If a similar variable
for links became widely supported, I would probably be a +1 on adding
support for it in coreutils. But I don't think any of us (feel free to
correct me if I am wrong) have the desire to come up with and
"standardize" a variable like that. So until then, this plan seems
reasonable.
> It would also be straightforward to make `NO_COLOR` in the environment a
> synonym for grotty's `-c` option if the initiative really catches fire.
> `GROFF_NO_SGR` is already there and does the same thing. (Strictly,
> grotty would "go too far" per the Q&A's above, but at present that
> doesn't concern me. You ask for monochrome, you get it.)
Yeah, I kind of feel the same way. But I would probably try to stick to
the standard to avoid suprising people.
By the way, I assume there is no need to mention my lack of
understanding of groff, man, etc., but is there a more standard way to
invoke groff to remove links than this?
$ groff -Z -Tutf8 -man man/ls.1 | grotty -c
Collin
[1] https://www.gnu.org/software/coreutils/rejected_requests.html#envvar
