I've got 256 colors working great in my terminal (test scripts here), but it stops working when I use ncurses (via Ruby-ncurses). Printing the escape sequences given on that page works fine, but when I initialize ncurses 'puts' stops working and I can't output the colors with any of the various ncurses color changing/string output functions I've found. What gives?
I am not sure if this would be all the story, but make sure your terminal capabilities do indeed provide for the 256 colors description.
What is the TERM environment variable value? Try setting it to xterm-256color and rerun it.
ncurses should then get the proper color escape sequences.
You can also test the terminal capabilities and terminal color output with the program we use at SXEmacs development:
http://www.triatlantico.org/tmp/tty-colors.c
Compile with gcc -o tty-colors tty-colors.c -lncurses
EDIT:
Note that just because the scripts that are found on the net output the 256 colors, that is not "all set".
Curses programs rely on terminfo and termcap and the TERM environment variable to find out how to interact with the terminal.
So in order for a curses app to be able to use the 256 colors one should set the TERM variable to an existing terminal name which supports 256 colors.
The C program above will show you what ncurses thinks about your terminal, not just output the xterm sequences like most scripts do [even the one from X.org]
njsf: You were partially right here, and after tinkering a lot more I eventually got it to work. Thanks for your help. The story: XTerm (and rxvt, and Eterm) support 256 colors via escape sequences (what I was seeing) but 'tput colors' will say '8' and ncurses won't be able to get at them, because ncurses is playing nice and attempting to access via terminfo.
For the benefit of anyone with similar pain:
I found I need to install the ncurses-term (Ubuntu) package to get /lib/terminfo/x/xterm-256color and other 256-color terminfo files. Then I set my TERM to xterm-256color and added the line '*customization: -color' to my ~/.Xdefaults, ran 'xrdb -merge ~/.Xdefaults' to load it, and from then on I have proper 256 color support in new xterms.
setting
ENV['TERM'] += '-256color' if ENV['TERM'] == 'xterm' # activate 256 colors
works on ubuntu 10.04 +
Related
I was playing around with Pytest --color=yes option and realized that my Terminal is printing results in color even without it being set.
Why is that?
My terminal setup is this:
OS: MacOS
iTerm2 build 3.4.15
iTerm2 Report terminal type property set to: xterm-256color
default shell is zsh (oh-my-zsh)
not sure if anything else matters...
My guess is it has something to do with oh-my-zsh, but I am not sure what, where and how.
I got to this question because I was trying to create SublimeText build system that will print results in colors, without success (not counting using SublimeANSI plugin which works with some quirks).
So, to reiterate the question: I am confused why my terminal app is printing Pytest results in color, even when no --color=yes is not set for Pytest.
If we look at the Pytest terminal source, we'll see the following on the color option:
group._addoption(
"--color",
metavar="color",
action="store",
dest="color",
default="auto",
choices=["yes", "no", "auto"],
help="color terminal output (yes/no/auto).",
)
So the default is set to auto.
Your zsh/oh-my-zsh allows to use the colors and therefore there shown without passing the option yourself.
I'm using Mac OS 10.13.4.
iTerm2 Version is Build 2.1.1
Vim Version is
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 29 2017 18:37:46)
Included patches: 1-503, 505-680, 682-1283
Compiled by root#apple.com
And I Installed the Vundle plugin
And when I open vim in iTerm2 with oh-my-zsh, the $p appears at the first line.
It doesn't appear with Terminal.app of Apple?
How to solve this problem?
vim is assuming that iTerm2 is xterm (not a good assumption), and attempting to determine the state of the cursorBlink resource by sending an escape sequence containing $p which iTerm2 does not handle properly (see source-code for vim for the escape sequence, and also where it uses the feature). While vim starts with the TERM setting (i.e., "xterm"), it does make a few checks to exclude things like gnome-terminal as noted in the source code comment. But iTerm2 happens to fool vim in this case. So the result goes to the screen.
In XTerm Control Sequences that is documented like this:
CSI ? Ps$ p
Request DEC private mode (DECRQM). For VT300 and up, reply is
CSI ? Ps; Pm$ y
where Ps is the mode number as in DECSET/DECSET, Pm is the
mode value as in the ANSI DECRQM.
Two private modes are read-only (i.e., 1 3 and 1 4 ), pro-
vided only for reporting their values using this control
sequence. They correspond to the resources cursorBlink and
cursorBlinkXOR.
Although vim is fooled here, the problem is due to iTerm2, for which you've probably set the TERM environment variable to xterm-256color, or something like that. It doesn't match iTerm2's behavior very well (the function keys don't match up, etc). ncurses provides a better one. But out-of-the-box MacOS has a terminal database that's about ten years old, and lacks that entry. To get a good terminal database (i.e., one where you could set TERM to iterm2), you could do that with MacPorts or home-brew.
Running infocmp to get a measure of the differences between the (correct) iterm2 entry and linux, xterm-256color shows that
it's actually closer to nsterm-256color (a correct entry for Terminal.app which Apple doesn't provide) with 38 lines of difference,
next closest linux with 76 lines and
still further away from xterm-256color with 94 lines.
The feature that's missing or mis-implemented in iTerm2 isn't in the terminal description: it's a special feature that vim has to guess about.
As mentioned above, this $p is due to vim sending a control sequence for a cursor blink request. In your .vimrc, you can turn off the cursor blink request by clearing the t_RC terminal option. I wrapped this in a conditional which turns it off only for 256 color terminals.
if &term =~ '256color'
set t_RC=
endif
Setting the terminal explicitly to linux solved it for me:
export TERM=linux
The p means print, which is the command the range is being given to, and yes.. it displays to you what is in that range.
In vim you can look at :help :range and :help :print to find out more about how this works. These types of ranges are also used by sed and other editors.
They probably used the 1,$ terminology in the tutorial to be explicit, but note that you can also use % as its equivalent. Thus, %p will also print all the lines in the file.
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!!!
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\]"
I'm using OSX snow leopard, for the record.
When I use emacs straight from terminal, I have a color set (e.g. for c/c++) that I'm very happy with---green on black, red comments, colored key words... etc etc. Some of this is set in my 'terminal preferences', and some is in my ~/.emacs file (see below). When I run emacs from screen, the basic color-scheme is the same (green on black), but the coloring is different (e.g. comment characters are red, but not the entire comments) -- and really annoying.
Any help would be appreciated!
In my '.emacs' file (this stops working in gnu-screen emacs):
(global-font-lock-mode t)
(custom-set-faces
'(font-lock-comment-face
((((class color) (background light))
:foreground "tomato")
)))
In my '.screenrc' file:
shell -$SHELL # colors still don't work without this
#term xterm-256color # using this doesn't fix the colors (suggested on some forums)
altscreen on
startup_message off
I thought that the command 'shell -$SHELL' in my .screenrc file made the command prompt in screen the same as the default --- it does make my command line say 'computername:/DIR/ username$' instead of just 'bash-3.2$'
=================================================================
Solution: Thanks to Greg E.
I needed to set my terminal emulator in screen to match that of my normal shell. To do this, I added
export TERM='xterm-color'
to ~/.bash_profile
For some reason, 'term xterm-color' in the '~/.screenrc' file didn't work.
My suspicion is that, while your terminal may be compiled with support for more than the standard 16 colors, your particular version of GNU screen may not be. I'm not very familiar with OSX, but on Linux I'd check whether the output of tput colors differs between a plain terminal and one running screen (I'd expect there to be some OSX equivalent if tput is not available). If it does, you may need to install (or manually compile) a different build of screen that includes support for additional colors (normally, 256 is the maximum, but 88 is also common, while 16 is the default minimum).
Edit: Ultimately, the correct solution proved to be manually setting the $TERM environment variable (see comments below).
I'm having trouble getting tmux to display lines for borders. They are being created with x and q. It's a debian squeeze server and the locale is set to en_US UTF8. I also tried adding
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lines to .tmux.conf. Nothing seems to work. I'm not sure if it's a locale issue or not. It displays correctly on other servers, but not the debian. I appreciate any tips you could offer! Thanks...
I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) I didn't get the correct line drawing.
Setting the Remote character set to "Use font encoding" did the trick for me.
There is some mismatch between your terminal emulator and the terminfo database entry being used by tmux (the one named by the TERM environment variable when you start/attach to a tmux server).
Per the VT100 User Guide, Table 3-9: Special Graphics Characters, when the “special graphics set” is selected, x is used to draw the “Vertical bar” and q is used to draw “Horizontal line - Scan 5”.
Under terminfo, the VT100 special graphics characters are available as a part of the Alternate Character Set functionality; see the “Line Graphics” section of the terminfo(5) man page.
Probably (on your Debian server) the effective terminfo database entry indicates that ACS is available, but your terminal emulator is not actually responding to the specified control sequences.
The tmux CHANGES file indicates that some terminal emulators (e.g. Putty) do not respect the ACS control sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that makes it always use UTF-8 characters instead of ACS sequences when the attaching client specifies that it can handle UTF-8 (i.e. when attaching, -u was given or UTF-8 is present in LC_ALL, LC_CTYPE or LANG; the utf8 window option is about what tmux should expect from the programs it runs, not what it can send to the attached client).
Debian “squeeze” only includes tmux 1.3, so your tmux probably does not have the “prefer UTF-8 line drawing” feature (unless it pulls from a backports source).
If you can not fix your terminal emulator nor upgrade to at least tmux 1.4, then you might be able to use tmux’s terminal-overrides option to unset the ACS-related capabilities so that tmux will fall back to ASCII line drawing. In your .tmux.conf (on the Debian system):
set-option -ga terminal-overrides ',*:enacs#:smacs#:rmacs#:acsc#'
Try setting the character set to "UTF-8" and "Use Unicode line drawing code points" under Window -> Translation in your putty settings.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
If you have Putty 0.73 or higher open settings, expand Window category, then select Translation. Check 'Enable VT100 line drawing even in UTF-8 mode':
I ran thru the gamut of suggestions including:
confirming locale and UTF-8 setting in PuTTY
exporting NCURSES_NO_UT8_ACS=1
manually trying various fonts and PuTTY translation selections
Above did not work. Dialog displays showed qqqq... and xxxx with various corner characters.
Changing all dialog calls to include --ascii-lines was an option but it would involve a lot of script changes.
Best recommendation was to change the Remote Character Set to Use font encoding.
PuTTY Change Settings --> Window --> Translation --> Remote Character Set --> Use font encoding
Left all other PuTTY settings default.
I changed the setting in Putty for terminal to Latin-1 and that seemed to fix the problem.
If you are using KiTTY there is a check box under Windows -> Translation tab, that is called "Allow ACS line drawing in UTF". It needs to be checked:
For me the issue was I forgot to make a locale.conf file when I setup this Arch Linux box. Below line fixed the issue, substitute your own language. A reboot was not required for me.
echo "LANG=en_US.UTF-8" > /etc/locale.conf
under windows/ putty the font you use has to have the characters for it to display
set translation "UTF-8" and "Use Unicode line drawing code points" and font to "courier-new" and most of those problems go away
It seems the font choice is a confusing factor here, to wit:
Lucida sans doesn't display UTF-8 line drawing, only - + | (pipe)
substitution
Courier New Bold does horizontal lines but |
substitution for vertical
Courier New Normal does 'em all.