This Is A Growing Standard To Disable Terminal Color

There’s tons of terminal apps with color nowadays but no consistent standard for disabling that color in the many cases where it isn’t needed, NO_COLOR aims to fix that.

==========Support The Channel==========
► $100 Linode Credit:
► Patreon:
► Paypal:
► Liberapay:
► Amazon USA:

No_Color Website:

=========Video Platforms==========
🎥 Odysee:
🎥 Podcast:
🎮 Gaming:

==========Social Media==========
🎤 Discord:
🎤 Matrix Space:
🐦 Twitter:
🌐 Mastodon:
🖥️ GitHub:

🎨 Channel Art:
All my art has was created by Supercozman

#Terminal #NoColor #Linux

🎵 Ending music
Music from
“Basic Implosion” by Kevin MacLeod (
License: CC BY (

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.

17 thoughts on “This Is A Growing Standard To Disable Terminal Color

  1. What software can we use to ban all the terminal emulators from setting the color "black" as light-grey? Dunno what I'm missing but holy moly does it drive me nuts.

  2. I'm writing this the second time now, as my post vanished. I hope for a YT error rather than you having deleted me on first sight 😉 So here we go (again):

    Hey Brodle, I am a (virtual) terminal emulator developer. I could talk all night long on your thoughts and my feedback on them. Time's short at night, but feel free to contact me on anything.

    >> Your Idea of no_color as a terminal feature

    On first sight, that sounds like an interesting idea, but implementing it into a TE will require application support, i.e. a shell integration such that the terminal knows what command is being run as it starts, and when it finishes. These kind of shell integrations do already exist to some degree and could be further extended respectively.

    0.) Implement it in the TE: Will require shell integration support to accurately tell the TE at which cursor position (line) an application starts (a stop should not be needed as your shell itself is also an app and it can advertise it self as itself, e.g. "zsh"). This solution would make it specific to that TE that's implementing it, while it might very well be implemented outside and every TE user (regardless of what his/her favourite TE is) could use that then.

    1.) Implement a no-color CLI tool that filters stdin. While that sounds rather easy, I'd be reserved on that. There is more than color. Also, this approach would only work on applications that don't alter the screen buffer (there is primary and alt buffer) nor would it work on user-interactive applications or those that simply query the terminal for some intormation where stdout/stdin is also used as communication line with text that's not even shown on the terminal but is still happening (!).

    2.) Alternative approach would be to implement it as a prefix-tool that spawns the application to be color-altered. Imagine you want the program `mc` to be color-altered, so call `nocolor mc`. Such a tool would spawn the program that was supplied via CLI parameters and communication happens via a new PTY specifically created by `nocolor` to communicate. Implementation complexity would be more than solution-1, but certainly more correct and more compatible.

    But the biggest problem I'd see in where to draw the line in customizability. Simply no color, or actually repurposing indexed colors as well as RGB ? Users never surrender to new ideas 😉

    >> A word on standardization

    Standard are cool, we should have them. In the TE-land however, we do in fact have (ancient) standards, and defacto standards. There's xterm, which is the terminal that everybody is reasoning conformance on. Even if xterm is having bugs, most likely other TEs are implementing that buggy behaviour. Getting rid of these bugs requires a (sometimes big) little bit of politics and stamina to get the changes adapted in as many TEs as possible.
    Some years ago there was an actually great idea by some TE devs and so the so called "terminal-wg" (working group) was formed. Sadly that forum is defacto-dead now, due to no real lead, too many wolves, and a few with a too strong opinion and too little focus on soft skills. Now the communication basically happens like a sparse network. Communication happens in many TE dev forums (most likely on Github, some on Gitlab) of each TE project space. Some are more willing and open to (constructively) communicate, some less (sadly).

    >> Images in the Terminal

    Interesting that you mention that. What exactly are you thinking of here as a video? Message me.
    Next. There's Sixel since decades. And Sixel is on the rise in recent years due to younger generation and the web (I guess), just like Emoji in the terminal and complex unicode in general in the terminal (not to mention Ligatures). While Sixel support is slowly emerging in quite some TEs nowadays (as in: past 2-3 years), there have been some proprietary protocols introduced (the one from Kitty as well as iTerm plus some JavaScript based TEs actually supporting an <image>-like tag in a terminal.
    It seems like every TE dev agreed on that Sixel is bad and should not be implemented, none of the existing proprietary could be agreed on as new/next defacto standard either.
    So Egmont (former well respected TE dev) came up with an article of thoughts, named: "Good" image protocol. When he semi-left the community, I took up his idea and started drafting out a spec and unfinished PoC until some private life priorities rearranged my life. That is soon over and I think I can resume the work, and I'm mentioning that as we have a forum there too with quite some TE devs from different corners that seemed to support the idea of pursuing this path.

  3. Hi, I in fact knew about the thing that sending output through a pipe never includes colors (and that the source command somehow had to check for it), because this is why we mis the colors when piping to a "less" or "more". I would like to see those colors there by default too.

  4. I prefer the colour. Had to install special fonts also for themes for 256 colours RGB for vim and tmux. Default is to have only 16.
    Something I had to figure out, to implement properly bash powerline.

  5. Seems useless to me, is anyone actually using it?
    Because surely everyone(everyone that is not literally blind at least), would want color in some cases, so they'd have to add and remove the environment variable before running their programs.
    Honestly, I really don't see any benefit over having an argument to set the software to display no color.

  6. Felicidades, es un buen ejemplo. 4 sentadillas son unos REIKOO.Uno muchas y un buen ejercicio. Se deja ver que hay muy buenos resultados 😍👍 Saludos desde la Cd.. de world 🌹😉💖 los mortalesh abian apreciado tan hermosa mujer.k



    Hate colour

Leave a Reply

Your email address will not be published.