Maybe this (black and white mode) could be feature of a terminal emulator – rather than modifying every piece of software. e.g. Konsole has color schemes, where you can setup one, that ignores colors. ANSI metadata can be still present in the output stream of a program. It is similar to a web browser where you turn off CSS styles – the CSS metadata may be still present in the markup, just silently ignored.
If we are talking about redirecting the output stream to another process or file – the program can detect, whether STDOUT is a terminal or not… and many programs do this (then simple | cat will remove the colors). If there are still some unwanted colors, there is a Perl one-liner:
I think setting your terminal to use a monochrome theme would be a quick workaround. I don’t know of any terminals that have it as a default theme option, but it might make for a reasonable first PR if anyone’s interested on working on it!
I knew someone who hacked suckless term to disable all color escapes/make them do nothing so the terminal was, always, black and white regardless of the program.
no_foo tends to be a poor variable name because it’s not extensible if you ever want to move away from booleans. COLOUR={off,some,lots,unicorn_vomit} would allow for more granularity.
I went to implement this in a rust project recently and found that it already worked since burntsushi’s termcolor crate checks for the envvar. Probably a lot of apps already handle this without the developers even realising it.
This is good to see. I tried running a program that happened to use color in 9term and the output was just unreadable because it doesn’t process ANSI escape codes. It would be nice to have a similar environment variable for disabling animations that use ANSI escape codes as well, like progress bars or anything that goes back and modifies lines and characters that were already printed.
like progress bars or anything that goes back and modifies lines and characters that were already printed.
That’s not ANSI escape codes, that’s just carriage return. And if your terminal doesn’t even support carriage return… well, I don’t have a strong urge to support your terminal.
Really though, you should enter the 70s and get a VT100-compatible terminal.
There’s no point arguing with legacy applications that require 70s’ VT100. Since you linked to 9term, below is something I use. This follows the same spirit of feeding a cat but replacing the cat with a supercharged nobs(1).
#!/usr/bin/env rc
. 9.rc
fn printf{awk 'BEGIN{printf "'$1'";exit}'}
b=`{printf '\b'}
r=`{printf '\r'}
ifs='' n=`{printf '\n'}
sed -l '
:b
s/[^'$b$r']'$b'//g
t b
s/[ '$r']*'$r'$//g
s/[ '$r']*'$r'/\'$n'/g' \
$*
I know bike shedding is probably inevitable but for what it’s worth, I would like to propose a slight modification. You mention for software to check the presence of this env variable, regardless of its value.
I would ask that instead, software checks to see if this value is TRUE. This way, I can place this env in /etc/skel to populate and let the users decide if they want to change the flag.
My thinking is that if this variable is instead not present at all, some users may not realize this is a settable value. Sure, you could put it in a man page for software that supports it, but then EVERY program that supports it would need to enter this in man pages over and over again!
I see your point, but I fear the way the NO_COLOR standard is written is a necessary compromise: it’s completely unambiguous and nearly impossible to get wrong for both users and implementers.
NO_COLOR=TRUE poses many questions. For example, is it case-sensitive? Should it accept commonly-used alternatives like 1, YES and similar?
It’s also still easy enough to make it discoverable:
# Uncomment the following line to disable ANSI color support in all applications
# that support the nocolor.org standard:
# NO_COLLOR=1
That could work. Even if it’s commented out, it still brings attention of the setting to the user.
As to the issue of sanitizing for yes, Yes, YES, 1, etc… It might be easier to just check for anything non-zero or perhaps NULL as any million other combinations can mean yes / true. Seems easier to check for false instead.
Sounds like the Unix model.™️
I like
hedgehog’s: https://github.com/hedgehogqa/haskell-hedgehog/blob/3d4dde46e15ab25a10cac0deff03bae10ecacc4e/hedgehog/src/Hedgehog/Internal/Config.hs#L100-L102Mark really doesn’t like colour, it seems.
Worth to note, that NO_COLOR has been started by @jcs, who you may also know for starting a rather popular site called lobste.rs.
Maybe this (black and white mode) could be feature of a terminal emulator – rather than modifying every piece of software. e.g. Konsole has color schemes, where you can setup one, that ignores colors. ANSI metadata can be still present in the output stream of a program. It is similar to a web browser where you turn off CSS styles – the CSS metadata may be still present in the markup, just silently ignored.
If we are talking about redirecting the output stream to another process or file – the program can detect, whether STDOUT is a terminal or not… and many programs do this (then simple
| catwill remove the colors). If there are still some unwanted colors, there is a Perl one-liner:I think setting your terminal to use a monochrome theme would be a quick workaround. I don’t know of any terminals that have it as a default theme option, but it might make for a reasonable first PR if anyone’s interested on working on it!
I knew someone who hacked suckless term to disable all color escapes/make them do nothing so the terminal was, always, black and white regardless of the program.
no_footends to be a poor variable name because it’s not extensible if you ever want to move away from booleans.COLOUR={off,some,lots,unicorn_vomit}would allow for more granularity.I went to implement this in a rust project recently and found that it already worked since burntsushi’s
termcolorcrate checks for the envvar. Probably a lot of apps already handle this without the developers even realising it.This is good to see. I tried running a program that happened to use color in 9term and the output was just unreadable because it doesn’t process ANSI escape codes. It would be nice to have a similar environment variable for disabling animations that use ANSI escape codes as well, like progress bars or anything that goes back and modifies lines and characters that were already printed.
That’s not ANSI escape codes, that’s just carriage return. And if your terminal doesn’t even support carriage return… well, I don’t have a strong urge to support your terminal.
Really though, you should enter the 70s and get a VT100-compatible terminal.
It’s not that I really desire support for it, I just like it when programs don’t rely on it or have an option not to.
There’s no point arguing with legacy applications that require 70s’ VT100. Since you linked to 9term, below is something I use. This follows the same spirit of feeding a cat but replacing the cat with a supercharged
nobs(1).Woah, thanks!
Most of the programs are “intelligent” enough, such that you only need to feed it to a cat to make the output plain.
Everyone always asks
isatty, but no one ever askshowsatty…I know bike shedding is probably inevitable but for what it’s worth, I would like to propose a slight modification. You mention for software to check the presence of this env variable, regardless of its value.
I would ask that instead, software checks to see if this value is TRUE. This way, I can place this env in /etc/skel to populate and let the users decide if they want to change the flag.
My thinking is that if this variable is instead not present at all, some users may not realize this is a settable value. Sure, you could put it in a man page for software that supports it, but then EVERY program that supports it would need to enter this in man pages over and over again!
I see your point, but I fear the way the NO_COLOR standard is written is a necessary compromise: it’s completely unambiguous and nearly impossible to get wrong for both users and implementers.
NO_COLOR=TRUEposes many questions. For example, is it case-sensitive? Should it accept commonly-used alternatives like 1,YESand similar?It’s also still easy enough to make it discoverable:
That could work. Even if it’s commented out, it still brings attention of the setting to the user.
As to the issue of sanitizing for yes, Yes, YES, 1, etc… It might be easier to just check for anything non-zero or perhaps NULL as any million other combinations can mean yes / true. Seems easier to check for false instead.