Suse 11 vs. Suse 10 diferenças que impactam as cores dos terminais?

Question

Eu tenho meus dotfiles versionados no github (garfo desavergonhado do bom trabalho de outras pessoas). No trabalho, eu os tenho em um servidor linux central (SuSE Enterprise Linux 10). Eu os rssync de um servidor de gerenciamento central para servidores de destino (eles geralmente não têm acesso http externo).

Lançamos o SuSE Enterprise Linux 11 e estou percebendo que os servidores "red" ou magenta bash prompt colors das minhas configurações de perfil não parecem estar funcionando. Da mesma forma, minhas configurações de esquema de cores vim não funcionam - por exemplo, em vez de realce de termo de pesquisa, a palavra desaparece. Vermelhos e amarelos não são honrados.

Alguém pode me indicar uma env env ou configuração que pode ser diferente nessas caixas do SLES 11? Abaixo estão as capturas de tela dos meus logins SLES10 vs SLES11 com dotfiles em sincronia (por exemplo, .bash_profile, .bash_prompt, .vimrc, etc).

$TERM em ambos os servidores é xterm-256color . ** veja as notas de atualização

De um servidor SLES10:

Mesmodotfiles,masemumservidorSLES11:

Atualizar

• Eu percebi que $ TERM era diferente se eu usasse SSH diretamente do meu estação de trabalho em comparação com o servidor do utilitário SLES10. Eu acredito que TERM está sendo encaminhado pelo servidor de utilitários.
• O script de inicialização .bash_prompt define $TERM com base na saída de infocmp que vem do pacote ncurses-devel que eu confirmei que não está na imagem do servidor SLES11. Se infocmp não for executado ou não estiver disponível, $TERM não será definido nem , seja lá o que foi antes do script ser executado .
• No caso de $TERM ser herdado (já definido), o script .bash_prompt a lógica condicional atualmente não é tocada quando infocmp não é executado.
• O script .bash_prompt usa os comandos tput para inicializar vários vars com códigos de cores - valores muito acima do padrão de 8 cores. tput é influenciado por $TERM .

Minha teoria atual: meu script PS1 setup pode estar emitindo alguns valores de terminal sem suporte - definidos anteriormente a partir de lógica condicional baseada em comandos que são influenciados pelo $TERM incorreto / não suportado. Isso, então, "atrapalha" os comandos subsequentes, como vim .

Alguém pode confirmar essa teoria com base no entendimento de tput e a influência de ncurses no sistema? Eu notei artigos sobre como as ncurses permitem mais valores de cor no terminal.

    

Answer 1

Tem certeza de que isso não é (parcialmente) um problema de configuração de vim ?

vim baseia-se principalmente na detecção do tipo de arquivo em nomes inteiros (por exemplo, .profile ) ou extensões ( .sh ). O arquivo que você deu é chamado (eu acredito) .bash_prompt , que não corresponde aos tipos conhecidos de bash ou shell.

Ao carregá-lo, o tipo detectado , e é diferente em cada sistema?

 :set filetype?

Se não for filetype=sh , tente

 :set syn=sh

(Eu suponho que pelo menos um digita conf filetype, que destaca # comments TODO e ' " strings citadas).

Eu suspeito que o SLES usa um pacote vim-data distinto, isso deve conter vários scripts de sintaxe e cores, verifique se ele está instalado no sistema SLES11.

Para ver qual formatação é aplicada à numeração de linhas, faça o seguinte:

:highlight LineNr

Se você não vir ctermfg=3 (cor terminal forground = amarelo), então isso explica porque o amarelo está "faltando".

Uma mudança no tipo de arquivo detectado explicará por que você está "faltando" magenta (vermelho e magenta não são da mesma cor, btw) em strings destacadas, e "faltando" amarelo se o LineNr foi alterado.

Se você tiver a fonte xterm em mãos, também poderá executar alguns de seus scripts de teste de cores que pode consultar todas as entradas de cores:

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

Você também pode achar útil o script colortest.vim , iniciar vim e executar

:runtime syntax/colortest.vim

Dentro de vim , execute :help xterm-color para obter mais conselhos sobre como certificar-se de que as cores base estão definidas conforme o esperado.

Tente verificar o que o Xterm acha que suas cores básicas devem ser (somente leitura quando o XTerm é inicializado):

xrdb -query | grep -i vt100.color