I've installed Karaf 4.1.0 and after opening the console, I've experienced that the commands were disappearing when I was typing them. After inspecting carefully, I've noticed, that their color changed to dark blue, which is for me almost indistinguishable from black background from the distance I sit from my monitor.
Is it possible to revert those colors settings and get back all commmands simply in visible white? It's very uncomfortable to type something you can't see...
In
$KARAF_HOME/etc/shell.init.script
add following command:
setopt disable-highlighter
then restart karaf.
The colors can be configured via property HIGHLIGHTER_COLORS as documented for the Apache Felix Gogo command line shell used within Karaf.
For instance assign
HIGHLIGHTER_COLORS = "fu=32;1:bf=31;1"
within the Karaf shell for bright green functions fu=32 and increased red bad functions bf=31;1 to gain improved readability on a black terminal background.
The color settings can be persisted to be enabled on each Karaf start via adding the above configuration line to the
karaf/etc/shell.init.script
You can use any Ansi Escape Code for configuring the shell color.
This works for us on Apache Karaf 4.1.2 and we are happy (again) now with the new coloring feature :-)
Related
In playing with the curses library, I discovered that if a default color is changed (say COLOR_BLUE, for example) using init_color, that changed color will continue to be used across stopping and restarting my program if I don't reset it back to its original definition. Even creating a new terminal window in which to run the program, the color of blue shows up as defined in the original windows. It even survives running a completely different program.
How is this happening? I would have thought the original definition would be used upon starting a new instance. I can only surmise that these default colors are cached somewhere at the OS level. Can someone explain what is happening here that allows this to happen?
I'm running this on a Centos 7.6 distro.
The colors are maintained/cached/whatever by a given terminal.
If the terminal description has this feature:
orig_colors oc oc Set all color pairs
to the original ones
that would be sent by the ncurses library as part of exiting curses mode.
It also might be sent by reset (or tput reset) command as part of the rs1 string. That's not automatic (and those commands do nothing special with color other than as a side-effect of the initialization and reset strings).
xterm supports a control sequence for resetting palettes back to their default, which was added to the terminal description in
2016-04-23
# + add 'oc' capability to xterm+256color, allowing palette reset for
# xterm -TD
referring to this:
oc=\E]104\007,
That uses OSC 104, which was developed for xterm in patch #252 (2009/12/7):
add OSC 104, for resetting ANSI/16/88/256 colors to default.
However, in discussing CentOS (RHEL), you have to keep in mind that it doesn't get updates for things like that:
The package information says that it has a development snapshot of ncurses from just a couple of days past 8 years ago.
Your terminal may/may not support the control sequence. If you are using xterm, no problem. For anything else (with that version of CentOS), you are out of luck. VTE developers (e.g., gnome-terminal) copied the feature in January 2014, but that version of VTE was released as 0.35.2, while CentOS 7 has 0.28.2
Vim & NeoVim both leave patches of simply black text scattered in random locations across the viewport. This is most common when scrolling or jumping between locations. This affect has happened on multiple different colorschemes so I suspect its more a problem with vim or my shell, than with the scheme. Generally when I load a file these patches don't exist, but they appear pretty quickly after starting vim. Reloading my configuration file or changing the scheme definitely makes them appear. Restarting the shell or quitting and restarting vim doesn't have any affect.
I'm running windows build 17763.92 on windows 10 Education & vim/neovim on Ubuntu (version 18.04 Bionic) bash for windows under the WSL.
Could anyone enlighten me as to why this is happening?
Heres my vim version info.
Heres my vimrc File & A Screenshot of The Described Affect.
This is usually caused by a wrong terminal setting in $TERM. The commands that Vim sends to the terminal to clear it then don't properly set the background color, and only text written on top has the correct background.
If you don't find a fix for that, you can work around the problem by clearing the background color of the Normal highlight group:
:hi Normal ctermbg=NONE
This happened to me as well, I would get black highlighting when opening a new line using o or O, and it would also appear when paging down (ctrl D) then scrolling up (k).
I was using vim (.vimrc - colorscheme desert with syntax on) on windows ubuntu subsystem WSL.
I was able to make it go away by updating my Windows 10 version 1909, to Windows 10 version 2004.
My problem was similar to this post: https://vi.stackexchange.com/questions/21437/vim-is-highlights-everything-after-eol-in-yellow-upon-scrolling
and, someone had also mentioned it being related to the terminal type xterm-256color here (their recommendation was to upgrade Windows version, it worked for me): https://superuser.com/questions/1526515/vim-highlighting-newlines-in-a-file-how-to-disable
I started using Fish (and oh-my-fish) a couple of weeks ago and one of the things that I find somewhat visually hard is the default background color of the autocomplete options (see the purple background in the image). I tried looking in the Fish page, but couldn't find anything related to that. I'd like to know how that background color can be changed.
In case you're wondering, I'm using LXTerminal in LUbuntu (a Ubuntu distro with LXDE).
it's more convenient to setup all color configuration via fish web UI, which can be done from cli:
fish_config colors, which launches the config server of fish, and there are already tons of predefined color suggestion
For more info, check out The Fish Shell
I found it, after checking these docs, and doing some trial and error with different environment variables that might be responsible for that feature.
The environment variable is fish_color_search_match
and the solution is changing the variable like:
$ set fish_color_search_match --background='333'
Where '333' is the color code. It is also possible to use predefined colors like cyan, green, blue, etc. that are available.
Also, I'm aware that maybe this belongs better in Unix&Linux StackExchange (which might have been the reason for the downvote?)
Edit: Take into account that colors will not look correctly if your terminal is not using 256 colors.
Adding to top voted answer. The command fish_config colors has been removed and you should instead use the following:
$ fish_config browse
The following also do the trick
$ fish_config
Reference: https://fishshell.com/docs/current/cmds/fish_config.html
I have setup ConEmu with Cygwin and Zsh quite a while ago. So far everything is working good.
I'm very interested in changing my oh-my-zsh theme to "agnoster"..
I've installed the powerline fonts and turned on the xterm256 colors as requested.
I'm still having problems with the colors though, the cwd path has the same color of the background (and appears to be hidden), no matter which color scheme I use.
Anyone had luck with that?
In my case, the issue was a combination of having a background image with a black background configured and the value for Replace Color Indexes being set to #1.
I had reset according to this comment:
After reading about -basic, I realized it something with my configuration. Reset it to default.. and configured from the beginning.. it works perfect now, I really really appreciate your help.
Everything was fine after the reset, so I went through and added my background image. That was fine, but because of the black background on the image and the fact that I was using transparency and a slightly off-black background, I started playing with that setting and once set to #1, it failed. I also noticed that the tooltip indicated that the default setting is #0 #1 (though after reset, it was set to *).
I have this problem on every host I run ConEmu on. Every host was setup several months ago and all have that same background image. I don't recall ever setting the Replace Color Indexes setting when I set it up -- heck, I didn't even know what that did so I can't imagine setting it. I'm guessing it might have been a default in an earlier version (I run the alphas) that, perhaps, carried over due to my setting it up a while ago?
I suspect, in my case, that this was the entire issue and that there wasn't something else going on. I saw the correct background to my prompt in PowerShell, but I use a hard-set value to an RGB color and take advantage of TrueColor ANSI support (which, when it fails, falls back to something that's not #0 or #1).
So, at least in my case, it definitely wasn't a bug -- it was doing exactly what it was asked to do, replacing a "blue" #1 background with the black from my image which yielded black-on-black text. I'll try changing that field on my other laptop exhibiting this problem when I'm home to confirm an alternative to resetting the entire configuration.
I've just installed Xmonad as my windows manager for Linux Mint 16. Its working fine except for one thing, there is no visible output when using terminal.
For example if I launch Firefox via terminal, the program loads up fine. However there is no output in terminal to show I have done this. Its as if the terminal output is being written in black rather than white.
Another example to more clearly illustrate my point, if I press the up arrow key, none of my previous executed input is shown.
I haven't touched any config files, its a clean install of Xmonad.
Any help would be appreciated. Again i've tried searching for the issue on Google but couldn't find anything.
SOLVED. Terminal was changing the output font to black due to the Xmonad settings. Solved by changing the terminal colour scheme to explicit white on black rather than system default.