7

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: vim session, sles 10, color scheme honored

Same dotfiles, but on a SLES11 server: vim session, sles 11, color scheme partially honored

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 of infocmp which comes from the ncurses-devel package which I've confirmed isn't on the SLES11 server image. If infocmp 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 when infocmp 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.

Scott Heaberlin
  • 121
  • 5
  • Have you tried specifying another basic color? Or just with xterm instead of the color version for $TERM just to see? –  Apr 03 '14 at 06:03
  • 1
    After some confusion due to forwarding of TERM over SSH, yes - xterm seems to have an impact though I don't think it's root cause. I'm updating the post with what I found. – Scott Heaberlin Apr 03 '14 at 14:42
  • dot files are not alone, they have global brothers and sisters, e.g. under /etc/profile.d and /etc/bash.bashrc, I tried to find them all in my blog http://www.linuxintro.org/wiki/Boot_process#user_starts_a_shell – Thorsten Staerk Apr 19 '14 at 20:30

1 Answers1

1

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?

 :set filetype?

If it's not filetype=sh then try

 :set syn=sh

(I'm guessing one at least says conf filetype, that highlights # comments TODO 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:

:highlight LineNr

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:

perl vttests/256colors2.pl            # fast, show all colors
perl vttests/query-color.pl 0-15      # slow, uninterruptable

You might also find the colortest.vim script useful, start vim and run

:runtime syntax/colortest.vim

Within 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):

xrdb -query | grep -i vt100.color
Community
  • 1
mr.spuratic
  • 9,721
  • 26
  • 41