I'm trying to get 256 colors in the fantastic ConEmu-Maximus5 console.
Update: Now it only shows 8 colors. I know because '$tput colors' output is '8'
I have followed the instructions and activated:
- TrueMod (24-bit color) support
- Inject ConEmuHk
- ANSI x3.64 / xterm 256 colors
I don't understand what to do with 'check off whether the buffer / slide.'
- I'm in windows 7.
- I start ConEmu with a custom direct link, so it loads cygwin bash file.
"C:\Program Files\ConEmu\ConEmu64.exe" /cmd ""C:\cygwin\bin\bash.exe" --login -i"
- In my bashrc profile I have -> export TERM=cygwin
- This is my custom command prompt:
function prompt { local RED="\[\033[0;31m\]" local GREEN="\[\033[0;32m\]" local COOLRED="\e[38;5;173m" local COOLGREEN="\e[38;5;113m" PS1="$COOLRED\u@\h $LIGHT_COOLGREEN\$PWD \[\e[0m\] > " } prompt
- The value of ConEmuANSI in ON, by the way.
I have some screen shots:
As you can see the command prompt looks very extravagant because it doesn't like the 256 color settings. If i substitute the variables COOLRED and COOLGREEN with RED and GREEN, then it looks ok, but it's not 256 colors.
More screenshots of the settings:
And the last sceen shot it's cygwin's mintty. Everything is ok there. Full 256 color supported. It's a shame mintty doesn't have tabs. That's mostly the reason why I'm trying to move to ConEmu.
Thank you very much for helping!!!
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:
*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:
Those
\e
s are probably from an e.g. Cprintf
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 readBash 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.
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
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.