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\]"
Related
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.
Is it possible to have the command prompt automatically run a command before every command that is entered?
The problem is sometimes when I kill the web server I am running to develop with in the command prompt with 'CTRL' + 'c' the process will change the color of the command prompt. This will linger in the command prompt and leave the color purple, making things hard to read. Currently when this happens I run color 07 before I start the server again. Is there a way to automatically run color 07 in the background when I type the next command so I always start with white?
You can adjust the prompt text by setting the PROMPT variable. This may allow you to use an ANSI escape code to reset the text color to default. Since some command prompt windows have ANSI color support turned on and some do not, it is difficult for me to tell if this will work as-is, but you can try it:
set PROMPT=$e[0m$P$G
If it does not work as-is, you could try one of a number of solutions to enable ANSI escape codes.
Since it sounds like you want the color command before you run the server, you can just make an alias to your command which runs both.
Try this?
Edit:
The general part of your question seems to be answered here for linux shell. If cygwin is available you could use that solution and still run your commands in windows. Could not find a trap equivalent for windows.
I just switched to a windows machine and I'm trying to get fish configured correctly. I installed it through the default route, as a shell selected through cygwin setup. It seems to be working fine, but when I directly access fish.exe or run fish.exe through IntelliJ, it outputs a ? before very prompt:
I googled and found this on fish documentation FAQ:
I'm seeing weird output before each prompt when using screen. What's wrong?
Quick answer:
Run the following command in fish:
echo 'function fish_title;end' > ~/.config/fish/config.fish
Problem solved!
The long answer:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
Note that fish has a default titlebar message, which will be used if
the fish_title function is undefined. So simply unsetting the
fish_title function will not work
So it appears that intelliJ and cmd (fish.exe runs in cmd.exe if you access it directly) do not support setting the title bar, so they just output the character to the terminal instead. However, their suggested solution does not work. I've tried various options like echoing an empty string or a space, but nothing gets rid of that darn question mark.
Has anyone else run into this and found a solution?
Notes:
It doesn't have this behavior when using fish through mintty.exe,
most likely since that terminal supports setting the title, but I really prefer
to use the terminal inside intelliJ instead of having it in a
separate window.
It didn't have this problem when I used fish through IntelliJ on Ubuntu or MacOSX, it appears to be isolated to Windows
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'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 +