xfce4-terminal ne lit plus .dircolors

3 réponses
Avatar
steve
Salut,

Depuis le passage à Stretch, ce terminal n'affiche plus fichiers en
couleurs selon l'extension.

La variable TERM est positionnée dans ~/.bashrc :

TERM_COLOR="$h_magenta\t$blanc $h_vert\u$blanc@$jaune\h$HOSTEXT$blanc:$vert \#$blanc $USERPROMPT "
TERM_NB="\t \u@\h$HOSTEXT:\w \#$USERPROMPT "
case "$TERM" in
"gnome-256color|Eterm"|"xterm"|"xterm-color"|"xterm-256color")
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
PS1="$TERM_COLOR\[\e[0m\]"
#TERM="xterm"
#TERM="gnome-256color"
TERM="xterm-256color"
;;
"linux"|"screen")
PS1="$TERM_NB"
;;
"dumb")
# terminal utilisé par scp lors des transferts
# il vaut mieux ne rien changer ici.
;;
*)
PS1="$TERM_NB"
echo "Terminal '$TERM' inconnu"
;;
esac

Juste au-dessus, j'ai

export LS_COLORS='--color=auto'
eval $(dircolors -b $HOME/.dircolors)

Par contre, xterm se comporte comme prévu.

Je ne sais où chercher.

Est-ce que quelqu'un a la même config que chez moi avec un comportement normal?

Merci d'avance

Steve

3 réponses

Avatar
=c3
steve, le 2017-07-11 :
Salut,

Bonjour,
Depuis le passage à Stretch, ce terminal n'affiche plus
fichiers en couleurs selon l'extension.
La variable TERM est positionnée dans ~/.bashrc :
TERM_COLOR="$h_magentat$blanc $h_vertu$blanc@$jauneh$HOSTEXT$blanc:$vert #$blanc $USERPROMPT "
TERM_NB="t $HOSTEXT:w #$USERPROMPT "
case "$TERM" in
"gnome-256color|Eterm"|"xterm"|"xterm-color"|"xterm-256color")
PROMPT_COMMAND='echo -ne
"33]0;${USER}@${HOSTNAME}: ${PWD}07"'
PS1="$TERM_COLOR[e[0m]"
#TERM="xterm"
#TERM="gnome-256color"
TERM="xterm-256color"
;;
"linux"|"screen")
PS1="$TERM_NB"
;;
"dumb")
# terminal utilisé par scp lors des transferts
# il vaut mieux ne rien changer ici.
;;
*)
PS1="$TERM_NB"
echo "Terminal '$TERM' inconnu"
;;
esac

Ça n'a peut-être rien à voir avec le problème présent, mais il me
semble distinguer une typo dans le premier cas du `case` :
"gnome-256color|Eterm"|"xterm" ...
devrait être :
"gnome-256color"|"Eterm"|"xterm" ...
Sinon les cas "gnome-256color" et "Eterm" ne se passent pas bien.
Juste au-dessus, j'ai
export LS_COLORS='--color=auto'
eval $(dircolors -b $HOME/.dircolors)

L'export de LS_COLORS en première commande n'est pas nécessaire,
car la variable sera écrasée lors du `eval` lisant fichier
~/.dircolors. D'ailleurs l'export initial n'a pas vraiment de
sens, car LS_COLORS décrit les couleurs à utiliser lors de
l'exécution d'un `ls --color` et non les options à passer par
défaut à `ls` (la page de manuel de `ls` est un peu floue à ce
sujet, mais c'est détaillé dans la page de manuel de la commande
`dircolors`).
Dans les fichiers de configuration de Bash fournis par défaut
dans Debian, ces fameuses options sont passées par des alias dans
le fichier ~/.bashrc. Par exemple :
alias ls='ls --color=auto'
Par contre, xterm se comporte comme prévu.

Pourquoi ça marche ? Cette question peut paradoxalement devenir
des plus frustrantes dans ce genre de cas.
Un détail peut jouer : le contenu de la variable TERM associée au
`xfce4-terminal` est passé de la valuer "xterm" à la valeur
"xterm-256color" en passant de Debian 8 à Debian 9, alors qu'au
lancement de `xterm`, cette valeur n'a pas changé et est restée à
"xterm". Mais si on s'en tient à l'extrait de votre script, ces
deux cas devraient être traités de manière identique.
Je ne sais où chercher.

Vous pouvez vérifier le contenu des différentes variables dans
les cas `xterm` et `xfce4-terminal` en exécutant les commandes :
echo "$TERM"
echo "$LS_COLORS"
Vous pouvex également voir si `ls` est un alias vers une commande
plus compliquée, comme `ls --color=auto` ou pas en utilisant la
commande :
alias ls
Par exemple j'ai (sans détailler le contenu de LS_COLORS, car
elle contient presque 1400 caractères pour décrire les extensions
de fichiers) :
$ echo $TERM
st-256color
$ echo $LS_COLORS
rs=0:di;34:ln;36:mh:pi3:so;35:do;35:b...
$ alias ls
alias ls='ls --color=auto'
Si ça peut vous donner des pistes...
À plus,
--
Étienne Mollier
Avatar
steve
Bonjour Etienne et merci pour cette réponse détaillée.
J'ai corrigé la petite typo (le " manquant).
Avant ta réponse, j'avais posé la question sur une autre liste et la
solution vient du fait que xfce4-terminal ne lit .bashrc que si bash est
utilisé comme un shell de connexion non interactif (pardon pour la
traduction). Ce qui n'est pas le cas de xterm. Par contre .bash_profile
est lu. Donc il fallait créer un fichier $HOME/.bash_profile avec dedans
[ -f "$HOME/.profile" ] && source "$HOME/.profile"
[ -f "$HOME/.bashrc" ] && source "$HOME/.bashrc"
et ensuite activer l'option
Lancer la commande en tant que shell de connexion
dans les préférences de xfce4-terminal.
Ce comportement a donc changé au passage vers Stretch et je n'ai pas
trouvé où cela était documenté.
Voilà, j'espère que cela pourra être utile à d'autres.
Encore merci pour l'intérêt.
Steve
Avatar
=c3
Bonjour Steve,
steve, le 2017-07-20 :
Avant ta réponse, j'avais posé la question sur une autre liste
et la solution vient du fait que xfce4-terminal ne lit .bashrc
que si bash est utilisé comme un shell de connexion non
interactif (pardon pour la traduction). Ce qui n'est pas le cas
de xterm. Par contre .bash_profile est lu. Donc il fallait
créer un fichier $HOME/.bash_profile avec dedans
[ -f "$HOME/.profile" ] && source "$HOME/.profile"
[ -f "$HOME/.bashrc" ] && source "$HOME/.bashrc"
et ensuite activer l'option Lancer la commande en tant que
shell de connexion
dans les préférences de xfce4-terminal.

Mes respects à la personne ayant identifié le problème. :-)
Je me suis fait moi-même piquer par cette particularité de Bash à
plusieurs reprises. Je dois passer trop de temps sur cette
horr^H^H^H^H sur Csh. >_<"
Voilà, j'espère que cela pourra être utile à d'autres.
Encore merci pour l'intérêt.

Ravi d'avoir pu (essayer d')aider. :-)
À plus,
--
Étienne Mollier
All opinion are my own.