J'utilise l'écran quotidiennement pour les besoins de mon terminal et j'en suis très satisfait. Récemment, cependant, je fait quelques mises à jour de mes fichiers de configuration de bash et j'ai remarqué que je mettais divers PATH
éléments ( PATH
, MANPATH
, INFOPATH
, etc.) en 2 endroits. J'ai modifié les fichiers pour qu'ils soient ce qu'ils devraient être et maintenant toutes mes variables d'environnement sont définies une fois .bash_profile
. C'est là que réside mon problème.
Apparemment, la raison pour laquelle je les installais à deux endroits était à cause de l'écran. écran apparaît seulement exécuter .bashrc
et ne pas semble hériter mes PATH
ou tout autre variables d' environnement correctement de mon shell bash d' origine. Parce qu'il s'exécute uniquement .bashrc
et que je ne place maintenant que mes variables .bash_profile
, j'obtiens un fichier incomplet PATH
.
Ma question est alors de savoir comment obtenir mes variables d'environnement à l'écran sans la duplication. La lecture des Bash
documents semble indiquer que ce pourrait être le type de shell que l'écran utilise pour se connecter, c'est-à-dire un shell interactif sans connexion, mais je ne pouvais pas comprendre comment forcer l'écran à utiliser un type de shell particulier, seul le shell à utiliser via -s /bin/bash
.
Vous pouvez parcourir mes fichiers de configuration sur ma page GitHub . C'est le commit commit qui a cassé l'écran .
EDIT: J'utilise Screen version 4.00.03 (FAU) 23-Oct-06
et j'ai tendance à l'invoquer enscreen -h 50000
EDIT: J'ai maintenant pu tester cela sur Cygwin ( CYGWIN_NT-5.1 1.7.1(0.218/5/3) i686
, Screen version 4.00.03 (FAU) 23-Oct-06
) et il présente un comportement différent de celui de mon Mac.
Le comportement spécifique que j'ai découvert est que, dans Cygwin, les modifications que PATH
j'apporte dans .bash_profile sont dupliquées lors de l'entrée dans l'écran, puis la création successive de fenêtres d'écran ne duplique pas le chemin, mais re-source .bash_profile.
Pour illustrer le comportement dont je parle:
Sortie d'un nouveau terminal:
...
PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack
MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man
Aliases:
alias ..='cd ..'
alias ...='cd ../..'
...
[~]$
Sortie de la première invocation d'écran:
[~]$ screen -h 50000 -s -/bin/bash
...
PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack
MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man
Aliases:
alias ..='cd ..'
alias ...='cd ../..'
...
[~]$
Appels ultérieurs à C-a c
:
...
PATH: /home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/home/tvishe01/bin/emacs/bin:/home/tvishe01/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/groovy-1.6.1/bin:/usr/lib/lapack
MANPATH: /home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man:/home/tvishe01/share/man:/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/ssl/man
Aliases:
alias ..='cd ..'
alias ...='cd ../..'
...
[~]$
Tu peux voir
la source
Réponses:
écran et variables d'environnement
Par défaut, screen transmet à ses shells (et autres processus) quelles que soient les variables d'environnement qu'il avait au démarrage de la session (c'est-à-dire que la reconnexion ne change pas quelles variables d'environnement sont données aux nouveaux shells). Mais parce que les fichiers de configuration d' écran et de shell changent généralement les variables d'environnement, il existe de nombreux endroits où des modifications inattendues peuvent être introduites. Il y a quelques variables, comme TERM , que l' écran change presque toujours, mais celles-ci sont généralement requises pour les fonctionnalités que l' écran fournit.
Disons que ni la configuration de votre shell, ni la configuration de l' écran ne modifiera une variable nommée FOOBAR (assez probablement, dans l'ensemble). Si vous démarrez une session avec
FOOBAR=foo screen
, tous les shells créés dans cette session auront une variable d'environnement nommée FOOBAR avec une valeur defoo
.Les choses deviennent plus compliquées pour les variables que l' écran ou votre shell peuvent modifier.
Paramètres manquants lors de l'utilisation de l' écran
Coquilles de connexion
Si vous constatez que certains paramètres sont manquants dans les shells démarrés par l' écran , c'est peut-être parce que votre shell est configuré uniquement pour mettre à jour ces paramètres pour les shells de «connexion». La plupart des shells comprennent une convention spéciale (en C:)
**argv == '-'
que l' écran peut être configuré pour utiliser.Selon la documentation de l' écran :
Pour avoir des shells de démarrage d' écran en tant que shells de connexion, démarrez l' écran avec
screen -s -/bin/bash
ou ajoutez cette ligne à votre.screenrc
:Ajustez le chemin vers le shell que vous utilisez.
configuration de l' écran
Les variables d'environnement manquantes ou réinitialisées peuvent également être dues à
setenv
et auxunsetenv
commandes d'un fichier de configuration d' écran . Vous devrez vérifier à la fois le .screenrc dans votre répertoire personnel et le fichier que votre compilation d' écran utilise comme 'system screenrc' (vous pouvez essayer une commande commestrings "$(which screen)" | fgrep -i screenrc
trouver le chemin d'accès qui a été configuré au moment de la compilation - c'est généralement / etc / screenrc pour un écran installé par le système ; les installations complémentaires utiliseront probablement un autre nom de chemin). Vous pouvez utiliserSCREENRC=/dev/null SYSSCREENRC=/dev/null screen
pour éviter temporairement ces fichiers de paramètres, mais il existe une option de compilation qui empêche l'utilisation efficace de SYSSCREENRC (probablement pour que les administrateurs système puissent forcer un peu de configuration initiale).Paramètres en double lors de l'utilisation de l' écran
Il est assez courant d'ajouter des éléments à une variable d'environnement comme PATH dans les fichiers de configuration d'un shell afin que la valeur mise à jour soit disponible pour les sessions shell normales (par exemple xterm ou autres fenêtres de terminal, sessions de console, etc.). Si de tels éléments sont ajoutés dans la configuration par shell d'un shell (ou, si vous utilisez le
-/path/to/shell
paramètre décrit ci-dessus, dans la configuration par shell de connexion), le shell démarré par l' écran aura probablement plusieurs copies des éléments ajoutés.Une stratégie pour éviter cela consiste à mettre tous les ajouts à des variables comme PATH dans la configuration par connexion de votre shell et à éviter d'utiliser le
-/path/to/shell
paramètre shell avec screen .Une autre stratégie consiste à ajouter conditionnellement les nouveaux éléments à la variable. Selon le shell, le code pour ce faire peut être un peu compliqué, mais il peut généralement être encapsulé dans une fonction shell pour une utilisation facile.
Encore une autre stratégie consiste à toujours commencer avec une valeur fixe dans vos fichiers de configuration. Cela peut parfois provoquer des problèmes lors du déplacement de vos fichiers de configuration d'un système à un autre lorsque les valeurs par défaut peuvent varier considérablement.
Diagnostique
Si vous ne pouvez pas repérer directement où une modification particulière se produit, vous pouvez essayer ce qui suit pour localiser où le changement se produit.
Vérifiez la valeur actuelle dans votre shell initial:
Vérifiez comment le shell lui-même modifie la valeur lors de la création d'un sous-shell:
Vérifiez comment le shell modifie la valeur lorsqu'un sous-shell de connexion est créé:
Vérifiez comment l' écran modifie la valeur:
la source
screen -s -/bin/bash
mais il ne se comporte pas car je m'attends à ce qu'il se comporte sous Cygwin sur ma machine de travail. Sur cette machine, je coursscreen -h 50000
et elle hérite simplement de monPATH
sans réellement réapprovisionner le fichier. Cela s'exécute à chaque fois que je lance une nouvelle fenêtre.FOOBAR=baz screen
vérifierecho $FOOBAR
les fenêtres shell à partir descreen
etscreen -s -/bin/bash
. Les deux variantes devraient avoirFOOBAR
=baz
. Si votrePATH
est en cours de modification, alors vous devrez retrouver ce qui le fait. EssayezSYSSCREENRC=/dev/null SCREENRC=/dev/null screen
, si cela vous permet dePATH
passer, alors c'est probablement unsetenv PATH
in/etc/screenrc
ou~/.screenrc
. Sinon, c'est quelque chose que vous.bashrc
faites.La dernière fois que j'ai vu un problème similaire, je l'ai résolu en utilisant
screen -l
lors du démarrage de l'écran.Vous pouvez utiliser l'
-l
option lors de l'appelscreen
(activer le mode de connexion ; également contrôlé par les commandesdeflogin
etlogin
dans.screenrc
) pour définir si l'écran doit ouvrir la fenêtre par défaut (ajouter / supprimer l'entrée / etc / utmp).Le mode de connexion est activé par défaut, mais il peut être modifié au moment de la compilation. Si screen n'est pas compilé avec le support utmp, ces commandes ne sont pas disponibles.
Je ne semble pas avoir besoin du
-l
mode dans l'écran par défaut de Debian Lenny (v4.0.3); il semble être activé par défaut. Mon~/.profile
et~/.bashrc
sont lus correctement. Comment invoquez-vousscreen
? Quelle version utilisez-vous?la source
screen -ln
devrait pas exécuter mon~/.profile
, et il est toujours exécuté. essayez donc le-l
drapeau, mais ce n'est probablement pas la bonne réponse. le laissera ici pour le moment.-l
seul contrôle siscreen
ajoute une entrée auutmp
fichier, pas s'il invoque de nouveaux shells avec leur propre-l
option ou utilise la-
coutume exec- with -prefix.Le problème réside dans le comportement de launchd sur Leopard. Consultez ce rapport de bogue MacPorts pour un écran sur Leopard pour voir pourquoi il ne sera jamais corrigé à moins que vous ne puissiez en quelque sorte rétroporter le lancement de Snow Leopard.
https://trac.macports.org/ticket/18235#comment:26
la source
Il n'y a rien de mal à trouver votre .bashrc à partir de .bash_profile. Si vous n'utilisez votre machine que localement, votre .bash_profile ne sera dans la plupart des cas sourcé que lors de votre connexion initiale (il y a évidemment d'autres fois où il est sourcé).
J'organise mes fichiers de sorte que si je veux que quelque chose soit fait uniquement lorsque je me connecte, je mets les informations dans .bash_profile et pour tout le reste je les mets dans .bashrc. PATH est une chose que je mets dans mon .bashrc, et je source .bashrc dans mon .bash_profile.
la source
.bashrc
et.bash_profile
quelque part afin que je puisse les voir? Le problème que j'ai rencontré en faisant quelque chose de similaire était quePATH
cela augmenterait à chaque fois que je créerais une nouvelle instance d'écran car elle hériterait de l'anciennePATH
et ensuite ajouterait tout à nouveau.Chaque fois que j'ai un problème comme ça , je crée un fichier
$HOME/.debug
et dans tous les fichiers est notre source / exécuté lors de la connexion / appel shell (par exemple~/.bashrc
,~/.bash_profile
,~/.profile
,/etc/bashrc
, etc.) J'ai la première ligneou similaire. Pour un débogage spécifique, vous pouvez également ajouter des éléments tels que
De cette façon, vous pouvez être sûr à 100% des fichiers utilisés ou non.
La redirection vers stderr est importante, vous ne voulez pas que quelque chose gâche stdout dans de nombreuses situations.
la source
Vous pouvez rester avec .profile car le système ne touche pas bashrc (comme la session graphique) Maintenant, vous avez simplement deux ensembles d'environnement différents - un à partir de .profile, l'autre pour bash à partir de .bashrc.
la source