web-dev-qa-db-fra.com

Comment définir l'environnement sans sourcing .bash_profiler moi-même à chaque fois?

Lorsque je redémarre Ubuntu 14.04, les variables d'environnement sont réinitialisées et je dois exécuter source .bash_profile à chaque fois, ce qui est très gênant. Je conserve généralement mes vars d'environnement dans .bash_profile dans le répertoire de base qui se trouve à /home/buraktas. C'est le texte du fichier:

### export Java_HOME variable
export Java_HOME=/usr/local/dev/jdk1.8.0_20
export PATH=$PATH:$Java_HOME/bin

### export M2_HOME
export M2_HOME=/usr/local/dev/maven
export PATH=$PATH:$M2_HOME/bin

### export SCALA_HOME
export SCALA_HOME=/usr/local/dev/scala-2.11.2
export PATH=$PATH:$SCALA_HOME/bin

J'apprécierai tout type de réponse.

bashloginenvironment-variables.profile
5
quartaela

TL; DR: Mettez vos commandes export dans _.profile_ à la place, supprimez ou renommez _.bash_profile_, puis déconnectez-vous et reconnectez-vous pour appliquer vos modifications.

Comment les fichiers "profil" par utilisateur sont utilisés

La plupart des environnements de bureau sont configurés par défaut, de sorte que le fichier _.profile_ de votre répertoire de base soit généré lorsque vous vous connectez graphiquement. On dirait que vous utilisez l'environnement de bureau par défaut d'Ubuntu, GNOME avec Unity. Cela devrait fonctionner.

La plupart des shells de style Bourne auront également pour source _.profile_, lorsqu'il est appelé en tant que shell de connexion . Ceci inclut bash , sauf que _.profile_ est généré uniquement si _.bash_profile_ et _.bash_login_ n'existent pas. Si _.bash_profile_ existe, il sera utilisé; sinon, si _.bash_login_ existe, il sera utilisé; et sinon, _.profile_ est utilisé.

La raison en est que les commandes ne dépendant pas du Shell, que vous voulez exécuter lors de la connexion, peuvent aller dans _.profile_, et s’il existe des commandes spécifiques à bash, vous pouvez les mettre dans un de ces deux autres fichiers. Habituellement, vous sourcez ensuite _.profile_ à partir de _.bash_profile_ ou _.bash_login_.

Si les seules commandes de _.bash_profile_ sont celles que vous avez montrées dans votre question, vous n'avez pas besoin d'utiliser _.bash_profile_ car ces commandes sont portables dans des shells de type Bourne. Vous pouvez ensuite supprimer _.bash_profile_ (ou le renommer comme suit: _.bash_profile.old_) et placer ces commandes dans _.profile_. Ils peuvent aller au bas de ce fichier et vous pouvez le sauvegarder en premier si vous le souhaitez (les noms raisonnables pour la sauvegarde peuvent être _.profile.old_ ou _.profile.orig_, mais vous pouvez nommer la sauvegarde comme vous le souhaitez. parce que ce n’est pas réellement utilisé).

L'absence de _.bash_profile_-- à condition que _.bash_login_ n'existe pas également - entraînera l'utilisation de _.profile_. (_.profile_ est probablement déjà utilisé pour votre connexion graphique.)

Que faire

Supprimer ou renommer _.bash_profile_.

Éditer _.profile_. Cela ressemble habituellement à ceci:

_# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
_

Vous pouvez simplement ajouter les onze lignes de code (six, si vous ne comptez pas les lignes vierges et les commentaires) au bas de _.profile_, enregistrez le fichier, puis déconnectez-vous.

Facultatif: vous pourriez envisager de réécrire ces affectations

Bien que cela soit tout à fait facultatif, vous voudrez peut-être saisir cette occasion pour refactor vos déclarations export. Actuellement, vous utilisez:

_### export Java_HOME variable
export Java_HOME=/usr/local/dev/jdk1.8.0_20
export PATH=$PATH:$Java_HOME/bin

### export M2_HOME
export M2_HOME=/usr/local/dev/maven
export PATH=$PATH:$M2_HOME/bin

### export SCALA_HOME
export SCALA_HOME=/usr/local/dev/scala-2.11.2
export PATH=$PATH:$SCALA_HOME/bin
_

PATH est modifié trois fois, une fois pour chaque autre variable affectée. C'est bon et c'est peut-être ce que vous voulez. Mais il est plus long et (à mon avis) moins auto-documenté que cette alternative:

_# export Java, Maven, and Scala homes and add their bins to PATH
export Java_HOME=/usr/local/dev/jdk1.8.0_20
export M2_HOME=/usr/local/dev/maven
export SCALA_HOME=/usr/local/dev/scala-2.11.2
export PATH=$PATH:$Java_HOME/bin:$M2_HOME/bin:$SCALA_HOME/bin
_

Si vous avez besoin de _.bash_profile_ Pour autre chose (mais ce n'est probablement pas le cas)

Je dois noter que ce que j'ai recommandé est très similaire à quelque chose c0rp dit précédemment (dans n commentaire sur n message qui a depuis été supprimé) :

Placez toutes les variables sur _~/.profile_ et source _~/.profile_ à partir de _~/.bash_profile_. _~/.profile_ est exécuté automatiquement par le DisplayManager pendant la session de travail du processus de démarrage ainsi que par le shell de connexion lorsqu ' se connecte à partir de la console textuelle .

Mais ma recommandation diffère sur un point important: comme il me semble que vous n’avez absolument pas besoin d’un fichier _.bash_profile_, je vous recommande de le déplacer simplement (par exemple, de le supprimer ou de le renommer), et non se préoccuper de l’approvisionner en _.profile_.

Si, pour une raison quelconque, vous avez besoin d’un fichier _.bash_profile_ , vous devez tout de même éviter d’avoir des définitions de variable d’environnement (car elles ne s’appliqueraient qu'à bash connexions, et non votre connexion graphique).

Si vous avez des commandes spécifiques à bash qui doivent aller dans un fichier _.bash_profile_, alors comme c0rp l'a dit, vous pouvez mettre cette ligne dans votre fichier _.bash_profile_:

_. $HOME/.profile
_

Alors _.bash_profile_ sera source _.profile_ et les commandes de _.profile_ seront exécutées à la fois pour les connexions bash et non bash.

Si vous utilisez _.profile_ ne fonctionne pas

Ensuite, plus de dépannage sera nécessaire, mais il convient de noter que:

  • Certains gestionnaires d'affichage source _.profile_ par défaut; certains ne le font apparemment pas.
  • Cela peut également dépendre de environnement de burea (je veux dire, des profils de session par DE qui indiquent au DM comment démarrer la session graphique).

J'ai entendu des gens dire que LightDM ne source pas _.profile_, et Je pense que cela est vrai au moins car il est fourni avec certains systèmes d'exploitation . Je ne peux absolument pas en parler, mais dans les systèmes Ubuntu que j'ai utilisé avec LightDM en tant que gestionnaire d'affichage, _.profile_ a été extrait dans des sessions graphiques et Les exportations de variables dans _.profile_ ont été efficaces.

(Cela n'a pas toujours fonctionné pour moi sur d'autres systèmes d'exploitation, tels que Debian.)

Si vous utilisez _.profile_ ne fonctionne pas: une alternative rapide et sale

Si vous êtes prêt à avoir une certaine redondance dans vos définitions de variable, vous pouvez utiliser _.pam_environment_ comme alternative rapide.

man pam_env explique qu'il est possible de définir des variables d'environnement sous forme de paires _KEY=VAL_ dans envfiles. Comme l'explique cette page de manuel, le fichier d'environnement système par défaut est _/etc/environment_ et les fichiers d'environnement par utilisateur par défaut sont _~/.pam_environment_.

Donc, vous pouvez créer un fichier _.pam_environment_ dans votre répertoire personnel et y insérer quelque chose comme ceci:

_Java_HOME="/usr/local/dev/jdk1.8.0_20"
M2_HOME="/usr/local/dev/maven"
SCALA_HOME="/usr/local/dev/scala-2.11.2"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/dev/jdk1.8.0_20/bin:/usr/local/dev/maven/bin:/usr/local/dev/scala-2.11.2/bin"
_

Comme vous pouvez le constater, pour changer quoi que ce soit, il vous faudrait faire plusieurs changements, et ce niveau élevé de duplication rend la lecture et la compréhension difficiles. C'est pourquoi je ne l'ai pas recommandé en premier.

Le moyen le plus simple et le plus auto-documenté dans votre situation consiste à définir et à exporter vos variables d'environnement dans _.profile_ comme décrit ci-dessus.

Les EnvironmentVariables article affirme qu'il est possible de modifier la valeur d'une variable d'environnement, et même d'inclure des extensions d'autres variables d'environnement, dans _.pam_environment_, avec une syntaxe telle que _PATH DEFAULT=${PATH}:${HOME}/MyPrograms_. Cependant, cela semble tout à fait incompatible avec la (plus)) documentation officielle , je l'ai essayé sur plusieurs machines sans succès, et je n'ai jamais entendu parler de son échec que pour les autres. Je soupçonne fortement les auteurs du wiki ont confondu la syntaxe pam_env "envfile" avec la syntaxe pam_env "conffile" (pour utiliser les termes employés dans man pam_env ). Espérons qu'un jour, quelqu'un parviendra à le découvrir avec certitude, et le wiki pourra alors être édité (pour correction ou clarification).

Pourquoi _.bash_profile_ fonctionne-t-il dans OS X?

OS X est l’un des rares environnements/systèmes où la configuration par défaut des terminaux sur son bureau graphique par défaut (c’est-à-dire les instances de Terminal.app) consiste à démarrer le shell en tant que shell de connexion plutôt qu’en tant que shell sans connexion. ( Cygwin en est un autre.)

Étant donné que chaque instance bash sur OS X lancée directement par Terminal.app (sauf si vous avez reconfiguré les éléments) agit comme un shell de connexion, _.bash_profile_ est recherché.

Je soupçonne que, en dehors des environnements accessibles via Terminal.app (ou une connexion non graphique, telle qu'une session SSH), les exportations au format _.bash_profile_ ne sont pas appliquées non plus.

La principale différence entre OS X et Ubuntu en ce qui concerne _.bash_profile_ est la suivante:

  • Sous OS X, les shells lancés par Terminal.app sont lancés en tant que shells de connexion. Puisque bash est le shell interactif par défaut sous OS X (depuis OS X 10.3 ou quelque chose du genre), _.bash_profile_ est obtenu s'il existe.

  • Dans Ubuntu, lorsque vous exécutez un terminal GNOME (ou un autre émulateur de terminal à interface graphique) à partir d'une session graphique, le shell en démarrage n'est généralement pas un shell de connexion. Les tâches effectuées par un shell de connexion ont généralement déjà été effectuées (généralement par le gestionnaire d'affichage) pour configurer la session graphique. L'idée est qu'il n'est pas nécessaire de les exécuter à nouveau.

    Il est également un peu étrange de démarrer un shell de connexion lorsque rien n’a ressemblé à une connexion.

3
Eliah Kagan