j'an ai marre de faire des conneries par ssh sur un machine distante en
croyant faire un manip sur la machine locale (et vice versa) simplement
parce que je mesuis planté de terminal.
Bon, je sais, je n'ai qu'à regarder le prompt pour savoir où je suis mais
quand même...
Comment faire pour clairement différencier (par la couleur du texte par
exemple) un terminal sur la machine locale d'un un terminal donnant un
accès à une machine distante ?
On Thu, 29 Oct 2009 10:10:18 +0100, Pierre Maurette :
Et idem pour identifier une fenêtre ouverte en root.
Il me semble que, quand tu es en root, le prompt se termine par un dièse. On ne peut guère se tromper.
Benoit Izac
Bonjour,
le 30/10/2009 à 00:18, Patrick Lamaizière a écrit dans le message <hcd7s6$13f$ :
Par contre je n'ai jamais réussi à faire marcher ça avec screen (même sans le test du $TERM), si quelqu'un a une idée?
Comme souvent, Google m'a donné la réponse (et j'aurais dû commencé par là) : <http://www.google.com/#q=xterm+title+screen>.
Testé et adopté. :)
Tu veux dire que ça marche ? Pas ici. Bon c'est pas grave.
Oui, j'ai juste rajouté termcapinfo xterm 'hs:ts=E]2;:fs= 07:ds=E]2;screen 07' dans mon ~/.screenrc, je suis sorti du screen en cours, et j'en ai relancé un nouveau (ce type de modification ne peut pas être fait interactivement). Si je fais un sleep 10, je le vois bien en titre de mon xterm. Je n'utilise pas csh mais zsh et j'ai ça dans mon .zshrc : case $TERM in xterm|screen) preexec () { print -Pn "e]0;%n@%m: $1a" } precmd () { print -Pn "e]0;[${TTY##*/}] %n@%m: %~a" } ;; esac
-- Benoit Izac
Bonjour,
le 30/10/2009 à 00:18, Patrick Lamaizière a écrit dans le message
<hcd7s6$13f$1@news.davenulle.org> :
Par contre je n'ai jamais réussi à faire marcher ça avec screen (même
sans le test du $TERM), si quelqu'un a une idée?
Comme souvent, Google m'a donné la réponse (et j'aurais dû commencé par
là) : <http://www.google.com/#q=xterm+title+screen>.
Testé et adopté. :)
Tu veux dire que ça marche ? Pas ici. Bon c'est pas grave.
Oui, j'ai juste rajouté
termcapinfo xterm 'hs:ts=E]2;:fs= 07:ds=E]2;screen 07'
dans mon ~/.screenrc, je suis sorti du screen en cours, et j'en ai
relancé un nouveau (ce type de modification ne peut pas être fait
interactivement). Si je fais un sleep 10, je le vois bien en titre de
mon xterm. Je n'utilise pas csh mais zsh et j'ai ça dans mon .zshrc :
case $TERM in
xterm|screen)
preexec () { print -Pn "e]0;%n@%m: $1a" }
precmd () { print -Pn "e]0;[${TTY##*/}] %n@%m: %~a" }
;;
esac
le 30/10/2009 à 00:18, Patrick Lamaizière a écrit dans le message <hcd7s6$13f$ :
Par contre je n'ai jamais réussi à faire marcher ça avec screen (même sans le test du $TERM), si quelqu'un a une idée?
Comme souvent, Google m'a donné la réponse (et j'aurais dû commencé par là) : <http://www.google.com/#q=xterm+title+screen>.
Testé et adopté. :)
Tu veux dire que ça marche ? Pas ici. Bon c'est pas grave.
Oui, j'ai juste rajouté termcapinfo xterm 'hs:ts=E]2;:fs= 07:ds=E]2;screen 07' dans mon ~/.screenrc, je suis sorti du screen en cours, et j'en ai relancé un nouveau (ce type de modification ne peut pas être fait interactivement). Si je fais un sleep 10, je le vois bien en titre de mon xterm. Je n'utilise pas csh mais zsh et j'ai ça dans mon .zshrc : case $TERM in xterm|screen) preexec () { print -Pn "e]0;%n@%m: $1a" } precmd () { print -Pn "e]0;[${TTY##*/}] %n@%m: %~a" } ;; esac
-- Benoit Izac
Lucas Levrel
Le 29 octobre 2009, Nicolas George a écrit :
.profile est destiné à recevoir les choses qu'on veut une fois par session, comme un affichage du nombre de nouveaux mails ou des anniversaires du jour.
De plus, on y met souvent l'initialisation de l'environnement,
Que désigne exactement le terme initialisation de l'environnement ?
Accessoirement, de mémoire, bash a une misfeature qui est que quand c'est un shell de login, il ne lit pas .bashrc. Il faut ajouter quelque chose comme « . ~/.bashrc » à l'extrême fin de .profile pour contourner ce bug.
Ah OK...
Le 8 octobre 2009, Nicolas George a écrit :
Date: 08 Oct 2009 14:11:49 GMT From: Nicolas George <nicolas$ Newsgroups: fr.comp.os.linux.configuration Subject: Re: Modifier le PATH pour un utilisateur sans toucher /etc/environment
> Ceci dit .profile source /etc/profile, qui source ~/.bashrc ...
Ce qui est un bug.
Ce n'est donc pas un bug mais un workaround.
-- LL
Le 29 octobre 2009, Nicolas George a écrit :
.profile est destiné à recevoir les choses qu'on veut une fois par session,
comme un affichage du nombre de nouveaux mails ou des anniversaires du jour.
De plus, on y met souvent l'initialisation de l'environnement,
Que désigne exactement le terme initialisation de l'environnement ?
Accessoirement, de mémoire, bash a une misfeature qui est que quand c'est un
shell de login, il ne lit pas .bashrc. Il faut ajouter quelque chose comme
« . ~/.bashrc » à l'extrême fin de .profile pour contourner ce bug.
Ah OK...
Le 8 octobre 2009, Nicolas George a écrit :
Date: 08 Oct 2009 14:11:49 GMT
From: Nicolas George <nicolas$george@salle-s.org>
Newsgroups: fr.comp.os.linux.configuration
Subject: Re: Modifier le PATH pour un utilisateur sans toucher /etc/environment
> Ceci dit .profile source /etc/profile, qui source ~/.bashrc ...
.profile est destiné à recevoir les choses qu'on veut une fois par session, comme un affichage du nombre de nouveaux mails ou des anniversaires du jour.
De plus, on y met souvent l'initialisation de l'environnement,
Que désigne exactement le terme initialisation de l'environnement ?
Accessoirement, de mémoire, bash a une misfeature qui est que quand c'est un shell de login, il ne lit pas .bashrc. Il faut ajouter quelque chose comme « . ~/.bashrc » à l'extrême fin de .profile pour contourner ce bug.
Ah OK...
Le 8 octobre 2009, Nicolas George a écrit :
Date: 08 Oct 2009 14:11:49 GMT From: Nicolas George <nicolas$ Newsgroups: fr.comp.os.linux.configuration Subject: Re: Modifier le PATH pour un utilisateur sans toucher /etc/environment
> Ceci dit .profile source /etc/profile, qui source ~/.bashrc ...
Ce qui est un bug.
Ce n'est donc pas un bug mais un workaround.
-- LL
Nicolas George
Lucas Levrel wrote in message :
Que désigne exactement le terme initialisation de l'environnement ?
Il me semble que, quand tu es en root, le prompt se termine par un dièse. On ne peut guère se tromper.
On peut trouver ça visuellement insuffisant ;-)
Chez moi, su donne toujours une invite rouge en gras. su tout seul laisse PS2 à >, et su - met PS2 à #.
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
Merci. -- LL
Le 30 octobre 2009, Fabien LE LEZ a écrit :
Il me semble que, quand tu es en root, le prompt se termine par un
dièse. On ne peut guère se tromper.
On peut trouver ça visuellement insuffisant ;-)
Chez moi, su donne toujours une invite rouge en gras. su tout seul laisse
PS2 à >, et su - met PS2 à #.
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour
m'instruire sur toutes les commandes cabalistiques du genre de celles qui
ont été citées (a.k.a. séquences d'échappement) ?
Il me semble que, quand tu es en root, le prompt se termine par un dièse. On ne peut guère se tromper.
On peut trouver ça visuellement insuffisant ;-)
Chez moi, su donne toujours une invite rouge en gras. su tout seul laisse PS2 à >, et su - met PS2 à #.
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
Merci. -- LL
Nicolas George
Lucas Levrel wrote in message :
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
Le fichier ctlseqs (qui peut être compilé en plusieurs formats) dans les sources d'xterm, contient une référence essentiellement exhaustive des séquences reconnues par xterm.
Lucas Levrel wrote in message
<Pine.LNX.4.64.0910301154481.4510@coulomb.univ-paris12.fr>:
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour
m'instruire sur toutes les commandes cabalistiques du genre de celles qui
ont été citées (a.k.a. séquences d'échappement) ?
Le fichier ctlseqs (qui peut être compilé en plusieurs formats) dans les
sources d'xterm, contient une référence essentiellement exhaustive des
séquences reconnues par xterm.
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
Le fichier ctlseqs (qui peut être compilé en plusieurs formats) dans les sources d'xterm, contient une référence essentiellement exhaustive des séquences reconnues par xterm.
Benoit Izac
Bonjour,
le 30/10/2009 à 12:14, Lucas Levrel a écrit dans le message :
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
console_code(4) a déjà été donné et constitue un bon départ.
-- Benoit Izac
Bonjour,
le 30/10/2009 à 12:14, Lucas Levrel a écrit dans le message
<Pine.LNX.4.64.0910301154481.4510@coulomb.univ-paris12.fr> :
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour
m'instruire sur toutes les commandes cabalistiques du genre de celles
qui ont été citées (a.k.a. séquences d'échappement) ?
console_code(4) a déjà été donné et constitue un bon départ.
le 30/10/2009 à 12:14, Lucas Levrel a écrit dans le message :
Tant que je suis dans ce fil... Quelle doc puis-je consulter pour m'instruire sur toutes les commandes cabalistiques du genre de celles qui ont été citées (a.k.a. séquences d'échappement) ?
console_code(4) a déjà été donné et constitue un bon départ.
-- Benoit Izac
Lucas Levrel
Le 30 octobre 2009, Nicolas George a écrit :
> Que désigne exactement le terme initialisation de l'environnement ?
Sur quels critères décides-tu où (.profile vs .*shrc) doit aller une commande export MAVARIABLE=... ?
-- LL
Nicolas George
Lucas Levrel wrote in message :
Sur quels critères décides-tu où (.profile vs .*shrc) doit aller une commande export MAVARIABLE=... ?
.*shrc n'est sourcé que par les shells interactifs. Or un shell interactif n'apparaît pas toujours dans l'ascendance d'un processus, par exemple un processus lancé depuis un menu du window-manager lui-même lancé depuis un display manager. Un paramètre d'environnement susceptible d'influencer une telle application ne doit donc en aucun cas se trouver dans .*shrc.
On reconnaît les variables d'environnement de ce genre à... ce que ce sont des variables d'environnement, et pas juste des variables du shell. On les reconnaît au mot clef export, justement. Donc en bref, export ne doit pas figurer dans .*shrc.
.*shrc est à réserver aux options qui influencent le comportement d'un shell interactif, donc :
- les options d'éditeur de ligne, de complétion, d'historique ; - les alias.
À noter que pour ma config personnelle, je n'utilise pas .profile mais .zshenv, qui est sourcé par toutes les instances de zsh quelles qu'elles soient. Ça permet de lui donner effet y compris dans des cas où il n'y a habituellement rien, comme une commande passée directement à ssh. Ça exige d'être prudent dans l'écriture, en particulier avec une protection contre une lecture multiple ou l'écrasement d'une modification explicite de l'environnement.
Lucas Levrel wrote in message
<Pine.LNX.4.64.0910301227590.4510@coulomb.univ-paris12.fr>:
Sur quels critères décides-tu où (.profile vs .*shrc) doit aller une
commande export MAVARIABLE=... ?
.*shrc n'est sourcé que par les shells interactifs. Or un shell interactif
n'apparaît pas toujours dans l'ascendance d'un processus, par exemple un
processus lancé depuis un menu du window-manager lui-même lancé depuis un
display manager. Un paramètre d'environnement susceptible d'influencer une
telle application ne doit donc en aucun cas se trouver dans .*shrc.
On reconnaît les variables d'environnement de ce genre à... ce que ce sont
des variables d'environnement, et pas juste des variables du shell. On les
reconnaît au mot clef export, justement. Donc en bref, export ne doit pas
figurer dans .*shrc.
.*shrc est à réserver aux options qui influencent le comportement d'un shell
interactif, donc :
- les options d'éditeur de ligne, de complétion, d'historique ;
- les alias.
À noter que pour ma config personnelle, je n'utilise pas .profile mais
.zshenv, qui est sourcé par toutes les instances de zsh quelles qu'elles
soient. Ça permet de lui donner effet y compris dans des cas où il n'y a
habituellement rien, comme une commande passée directement à ssh. Ça exige
d'être prudent dans l'écriture, en particulier avec une protection contre
une lecture multiple ou l'écrasement d'une modification explicite de
l'environnement.
Sur quels critères décides-tu où (.profile vs .*shrc) doit aller une commande export MAVARIABLE=... ?
.*shrc n'est sourcé que par les shells interactifs. Or un shell interactif n'apparaît pas toujours dans l'ascendance d'un processus, par exemple un processus lancé depuis un menu du window-manager lui-même lancé depuis un display manager. Un paramètre d'environnement susceptible d'influencer une telle application ne doit donc en aucun cas se trouver dans .*shrc.
On reconnaît les variables d'environnement de ce genre à... ce que ce sont des variables d'environnement, et pas juste des variables du shell. On les reconnaît au mot clef export, justement. Donc en bref, export ne doit pas figurer dans .*shrc.
.*shrc est à réserver aux options qui influencent le comportement d'un shell interactif, donc :
- les options d'éditeur de ligne, de complétion, d'historique ; - les alias.
À noter que pour ma config personnelle, je n'utilise pas .profile mais .zshenv, qui est sourcé par toutes les instances de zsh quelles qu'elles soient. Ça permet de lui donner effet y compris dans des cas où il n'y a habituellement rien, comme une commande passée directement à ssh. Ça exige d'être prudent dans l'écriture, en particulier avec une protection contre une lecture multiple ou l'écrasement d'une modification explicite de l'environnement.
