I have my dotfiles versioned on github (shameless fork of other people's fine work). At work, I have them on a central linux server (SuSE Enterprise Linux 10). I rsync them from a central management server to target servers (they often don't have external http access).
We've rolled out SuSE Enterprise Linux 11 and I'm noticing on those servers "red" or magenta bash prompt colors from my profile settings don't seem to be working. Similarly, my vim colorscheme settings don't work – for example instead of search-term highlighting, the word disappears. Reds and yellows aren't honored.
Can someone point me to an env var or setting that might be different on these SLES 11 boxes? Below are screenshots of my SLES10 vs SLES11 logins with dotfiles in sync (e.g. .bash_profile, .bash_prompt, .vimrc, etc).
$TERM
on both servers is xterm-256color
. **see update notes
From a SLES10 server:
Same dotfiles, but on a SLES11 server:
Update
- I noticed $TERM was different if I SSHed directly from my
workstation versus from the SLES10 utility server. I believe TERM is being forwarded from the utility server. - The .bash_prompt init script sets
$TERM
based on the output ofinfocmp
which comes from thencurses-devel
package which I've confirmed isn't on the SLES11 server image. Ifinfocmp
doesn't run or isn't available,$TERM
is left unset or whatever it was before the script ran. - In the event that
$TERM
is inherited (already set), the .bash_prompt script conditional logic currently leaves it untouched wheninfocmp
doesn't run. - The .bash_prompt script then uses
tput
commands to initialize several vars with color codes – values far above the 8 color default.tput
is influenced by$TERM
.
My current theory: my PS1
setup script may be emitting some unsupported terminal values – set earlier from conditional logic based on commands that are influenced by the incorrect/unsupported $TERM
. This then “messes up” subsequent commands like vim
.
Can anyone confirm this theory based on their understanding of tput
and the influence of ncurses
on the system? I've noticed articles about how ncurses enables more color values in the terminal.
Best Answer
Are you certain this isn't (partially) a
vim
configuration issue?vim
mostly bases its filetype detection on whole names (e.g..profile
) or extensions (.sh
). The file you gave is called (I believe).bash_prompt
, which won't match known bash or shell types.When you load it, what is the detected type, and is it different on each system?
If it's not
filetype=sh
then try(I'm guessing one at least says
conf
filetype, that highlights#
commentsTODO
and'
"
quoted strings).I suspect SLES uses a distinct
vim-data
package, this should contain various syntax and color scripts, check if this is installed on the SLES11 system.To see what formatting is applied to line numbering do:
If you don't see
ctermfg=3
(color terminal forground= yellow) then that explains why yellow is "missing".A change in detected filetype will explain why you are "missing" magenta (red and magenta aren't the same color, btw) on highlighted strings, and "missing" yellow if LineNr has changed.
If you have the xterm source to hand, you can also run some of its colour test scripts which can query all the colour entries:
You might also find the colortest.vim script useful, start
vim
and runWithin
vim
, run:help xterm-color
for further advice on making sure that the base colors are set as expected.Try this to check what is Xterm thinks its base colors should be (only read when XTerm starts up):