Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
=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.
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
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 u@h$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.
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 <etienne.mollier@mailoo.org>
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.
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
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
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
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
=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.
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
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 <etienne.mollier@mailoo.org>
All opinion are my own.
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.
