Can't enable 256 colors in ConEmu

烂漫一生 提交于 2019-12-02 16:19:21

Bash does not send ANSI sequences to console. It tries to process them itself. And, because *nix terminal is generally only 8-color (not taking into account 256-color mode), bash uses 8-color palette instead of 16-color palette which is common to Windows terminal.

I think, 256-colors works in mintty because _isatty returns zero in that terminal. But it returns non zero value under ConEmu. May be in future builds I solve this puzzle (how to create real terminal with PTY features for some applications).

As for the question

You have no need in 256-colors In fact. To redefine prompt palette you may use "Extend foreground colors with background" feature. In breaf - set up colors 16, 17, etc. in ConEmu, set prompt background in bash to #5 (configurable in ConEmu), and voila.

There was a small bug in ConEmu "Extend..." processing. Use build 121016 or later.

PS1="\e[30;45m\u@\h \e[34;45m$PWD \[\e[0m\] > "

Following info does not match the question, but may be useful

Current version does not support 256-color mode in 'whole' console buffer (limitation, yes, removing it in plans).

So, you can go 2 ways

  • totally disable scrollback buffer (many ways, for example "cmd -cur_console:h0")
  • work in the bottom of the scroll-buffer.

I also couldn't get 256 color support to work (the colors would show up, but they looked the same as the 16-color palette). I switched to the "xterm" color scheme and now it works in native Windows executables (such as Python) but not in anything that uses Cygwin. Cygwin appears to have terminal-escape-sequence processing that you can't turn off, which defeats the ConEmuHk injection.

This is documented on the ConEmu wiki, here.

I had this weird problem and the weird solution and somehow it works. and don't know if this is with others too, just some info-sharing in case this shall be helpful.

I like colouring my consoles and like to utilize the full real 256 bits of RGB colouring. After confuguring as in the conemu/CMDer (i used the forked one) instruction. my 256bit coloring test looked like this.

. After mucking around a bit and testing with my bash 256bit capability. i.e running this command:

for i in {1..16384}; do echo -en "\e[38;5;${i}mTest";done

*note supposed to be {1..256}, but i had to force it for a longer colour prints, so just took a longer random number.. giving the result:

But running some 2-3 times, i saw this clean gray shade suddenly

and it worked then on..

weird but i got this working. Could it be that CMDer is somehow not using the full 256 bit because of optimizing reason and it get triggered when it is kicked in??,

PS: my CMDer cmd for the console:

-cur_console:fp -cur_console:d:"C:\WS":P:"<Cobalt>":t:"test":C:"C:\Arbeit\tools\Iconka-Buddy-Ninja.ico" set "PATH=%ConEmuDrive%\Program Files\Git\usr\bin;%PATH%" & "%ConEmuDrive%\Program Files\Git\git-bash.exe" --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe /usr/bin/bash.exe -l -i
local COOLRED="\e[38;5;173m"

local COOLGREEN="\e[38;5;113m"

Those \es are probably from an e.g. C printf string. You don't want them in a shell script. Stick with the original \033 notation. Also you are missing the closing \]. These lines should now read

local COOLRED="\[\033[38;5;173m\]"

local COOLGREEN="\[\033[38;5;113m\]"
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!