Quelle est la bonne façon de modifier des variables d'environnement comme PATH dans OS X?
J'ai un peu regardé sur Google et trouvé trois fichiers différents à modifier:
- / etc / chemins
- ~ / .profile
- ~ / .tcshrc
Je n'ai même pas certains de ces fichiers, et je suis presque sûr que .tcshrc est faux, car OS X utilise bash maintenant. Où sont définies ces variables, en particulier PATH?
J'utilise OS X v10.5 (Leopard).
macos
bash
path
environment-variables
Paul Wicks
la source
la source
env "switch.1.disabled=true" open -n /Applications/Eclipse.app/
pour lancer l'application GUI avec un nouvel environnement système défini.Réponses:
Bruno est sur la bonne voie. J'ai fait des recherches approfondies et si vous souhaitez définir des variables disponibles dans toutes les applications GUI, votre seule option est
/etc/launchd.conf
.Veuillez noter que environment.plist ne fonctionne pas pour les applications lancées via Spotlight. Ceci est documenté par Steve Sexton ici .
Ouvrez une invite de terminal
Type
sudo vi /etc/launchd.conf
(remarque: ce fichier n'existe peut-être pas encore)Mettez du contenu comme le suivant dans le fichier
Enregistrez vos modifications dans vi et redémarrez votre Mac. Ou utilisez la commande
grep
/xargs
qui est indiquée dans le commentaire de code ci-dessus.Prouvez que vos variables fonctionnent en ouvrant une fenêtre de terminal et en tapant
export
et vous devriez voir vos nouvelles variables. Ceux-ci seront également disponibles dans IntelliJ IDEA et dans d'autres applications GUI que vous lancerez via Spotlight.la source
launchd.conf
est à sens unique, mais nécessite un redémarrage (pour redémarrer launchd). Si vous voulez éviter un redémarrage, voir ma réponse stackoverflow.com/questions/135688/…Comment définir l'environnement pour les nouveaux processus démarrés par Spotlight (sans avoir besoin de redémarrer)
Vous pouvez définir l'environnement utilisé par launchd (et, par extension, tout ce qui a commencé à partir de Spotlight) avec
launchctl setenv
. Par exemple, pour définir le chemin:Ou si vous souhaitez configurer votre chemin dans
.bashrc
ou similaire, faites-le en miroir dans launchd:Il n'est pas nécessaire de redémarrer, mais vous devrez redémarrer une application si vous souhaitez qu'elle reprenne l'environnement modifié.
Cela inclut tous les shells déjà exécutés sous Terminal.app, bien que si vous y êtes, vous pouvez définir l'environnement plus directement, par exemple avec
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
for bash ou zsh.Comment conserver les modifications après un redémarrage
Pour conserver les modifications après un redémarrage, vous pouvez définir les variables d'environnement
/etc/launchd.conf
comme suit :launchd.conf
s'exécute automatiquement au redémarrage.Si vous souhaitez que ces modifications prennent effet maintenant, vous devez utiliser cette commande pour retraiter
launchctl.conf
(merci @mklement pour l'astuce!)Vous pouvez en savoir plus sur
launchctl
et comment il se chargelaunchd.conf
avec la commandeman launchctl
.la source
environment.plist
n'est pas le cas.etc/launchd.conf
avant un redémarrage serait d'utiliser l'approche @ réponse de MatthewMcCullough:egrep "^setenv\ " /etc/launchd.conf | xargs -t -L 1 launchctl
.Jusqu'à OS X v10.7 (Lion) inclus, vous pouvez les définir dans:
Voir:
Pour PATH dans le terminal, vous devriez pouvoir le configurer
.bash_profile
ou.profile
(vous devrez probablement le créer cependant)Pour OS X v10.8 (Mountain Lion) et au-delà, vous devez utiliser
launchd
etlaunchctl
.la source
preferences.plist
n'était pas idéale avec OS X 10.5 car à cette époquepreferences.plist
n'était pas lu pour les applications lancées sous les projecteurs, voir le commentaire de Louis à la réponse de Matthew et email.esm.psu.edu/pipermail/macosx-emacs/2010-May /002113.html . Pour OS X 10.6environment.plist
fonctionne comme il se doit.Solution pour les applications de ligne de commande et d'interface graphique à partir d'une seule source (fonctionne avec Mac OS X v10.10 (Yosemite) et Mac OS X v10.11 (El Capitan))
Supposons que vous ayez des définitions de variables d'environnement dans votre
~/.bash_profile
comme dans l'extrait de code suivant:Nous avons besoin d'un agent de lancement qui s'exécutera à chaque connexion et à tout moment sur demande qui va charger ces variables dans la session utilisateur. Nous aurons également besoin d'un script shell pour analyser ces définitions et construire les commandes nécessaires à exécuter par l'agent.
Créez un fichier avec
plist
suffixe (par exemple nomméosx-env-sync.plist
) dans le~/Library/LaunchAgents/
répertoire avec le contenu suivant:-l
le paramètre est critique ici; il est nécessaire pour exécuter le script de shell avec un shell de connexion afin qu'il~/.bash_profile
soit originaire avant l'exécution de ce script.Maintenant, le script shell. Créez-le
~/.osx-env-sync.sh
avec le contenu suivant:Assurez-vous que le script shell est exécutable:
Maintenant, chargez l'agent de lancement pour la session en cours:
(Re) Lancez une application GUI et vérifiez qu'elle peut lire les variables d'environnement.
La configuration est persistante. Il survivra aux redémarrages et aux reconnexions.
Après la configuration initiale (que vous venez de faire), si vous souhaitez refléter à nouveau tout changement dans votre
~/.bash_profile
environnement, la réexécution de lalaunchctl load ...
commande n'effectuera pas ce que vous voulez; à la place, vous obtiendrez un avertissement comme celui-ci:<$HOME>/Library/LaunchAgents/osx-env-sync.plist: Operation already in progress
Pour recharger vos variables d'environnement sans passer par le processus de déconnexion / connexion, procédez comme suit:
Enfin, assurez-vous de relancer vos applications déjà en cours d'exécution (y compris Terminal.app) pour les informer des modifications.
J'ai également poussé le code et les explications ici vers un projet GitHub: osx-env-sync .
J'espère que ce sera la solution ultime, au moins pour les dernières versions d'OS X (Yosemite & El Capitan).
la source
Faire:
Le fichier peut ne pas exister (sinon, vous pouvez simplement le créer).
Tapez-le et enregistrez le fichier:
Courir
la source
export
était ce que j'allais suggérer, car BASH ne prend pas en chargesetenv
Il y a essentiellement deux problèmes à résoudre lors du traitement des variables d'environnement sous OS X. Le premier est lors de l'appel de programmes à partir de Spotlight (l'icône de la loupe sur le côté droit du menu Mac / barre d'état) et le second lors de l'appel de programmes à partir du Dock . Programmes à partir d' une invocation de l' application Terminal / utilitaire est trivial car il lit l'environnement à partir des emplacements standard du shell (
~/.profile
,~/.bash_profile
,~/.bashrc
, etc.)Lorsque vous appelez des programmes à partir du Dock, utilisez
~/.MacOSX/environment.plist
où l'<dict>
élément contient une séquence d'<key>KEY</key><string>theValue</string>
éléments.Lorsque vous appelez des programmes à partir de Spotlight, assurez-vous que launchd a été configuré avec tous les paramètres de clé / valeur dont vous avez besoin.
Pour résoudre les deux problèmes simultanément, j'utilise un élément de connexion (défini via l'outil Préférences Système) sur mon compte utilisateur. L'élément de connexion est un script bash qui invoque une fonction lisp d'Emacs bien que l'on puisse bien sûr utiliser leur outil de script préféré pour accomplir la même chose. Cette approche a l'avantage supplémentaire de fonctionner à tout moment et ne nécessite pas de redémarrage, c'est-à-dire que l'on peut modifier
~/.profile
, exécuter l'élément de connexion dans un shell et que les modifications soient visibles pour les programmes nouvellement appelés, à partir du Dock ou de Spotlight.Détails:
Élément de connexion:
~/bin/macosx-startup
Fonction Emacs lisp:
~/lib/emacs/elisp/macosx/envionment-support.el
REMARQUE: Cette solution est un amalgame de celles qui viennent avant que j'ajoute la mienne, en particulier celle proposée par Matt Curtis, mais j'ai délibérément essayé de garder ma
~/.bash_profile
plate-forme de contenu indépendante et de mettre le paramètre de l'launchd
environnement (une installation Mac uniquement) dans un script distinct .la source
EnvPane est une autre solution gratuite et open source de Mac OS X v10.8 (Mountain Lion) dans le volet Préférences / environment.plist .
Le code source d'EnvPane est disponible sur GitHub . EnvPane semble avoir des fonctionnalités comparables à RCEnvironment , mais il semble qu'il puisse mettre à jour ses variables stockées instantanément, c'est-à-dire sans avoir besoin d'un redémarrage ou d'une connexion, ce qui est bienvenu.
Comme indiqué par le développeur:
Avis de non-responsabilité: je ne suis en aucun cas lié au développeur ou à son projet.
PS J'aime le nom (sonne comme «Ends Pain»).
la source
Mise à jour (2017-08-04)
Depuis (au moins) macOS 10.12.6 (Sierra), cette méthode semble avoir cessé de fonctionner pour Apache httpd (pour
system
et pour l'user
option delaunchctl config
). D'autres programmes ne semblent pas affectés. Il est concevable qu'il s'agit d'un bogue dans httpd.Réponse originale
Cela concerne OS X 10.10+ (10.11+ spécifiquement en raison du mode sans racine où il
/usr/bin
n'est plus accessible en écriture).J'ai lu à plusieurs endroits que l'utilisation
launchctl setenv PATH <new path>
de la définition de laPATH
variable ne fonctionne pas en raison d'un bogue dans OS X (ce qui semble vrai par expérience personnelle). J'ai trouvé qu'il existe une autre façon dePATH
définir les applications non lancées à partir du shell :Cette option est documentée dans la page de manuel launchctl:
J'ai confirmé que cela fonctionne avec une application GUI démarrée à partir du Finder (qui utilise
getenv
pour obtenir PATH). Notez que vous ne devez effectuer cette opération qu'une seule fois et que la modification sera persistante lors des redémarrages.la source
sudo launchctl procinfo <gui-pid>
montre l'PATH
environnement nouvellement défini . Mais ensudo launchctl config user path <new path>
fait défini pour tous les utilisateurs ... (confirmé en ajoutant un nouvel utilisateur et en utilisant la console python de Sublime Text)sudo launchctl config user path
, que cela se produit (ce que vous semblez supposer?).launchctl
ne pas vous permet de définir des variables d'environnement arbitraires. LaPATH
variable est une exception.Sur Mountain Lion tous les
/etc/paths
et l'/etc/launchd.conf
édition ne fait aucun effet!Les forums des développeurs d'Apple disent:
J'ai donc édité directement l'application
Info.plist
(clic droit sur "AppName.app" (dans ce cas SourceTree) puis "Show package contents
").Et j'ai ajouté une nouvelle paire clé / dict appelée:
(voir: Documentation LaunchServicesKeys sur Apple )
Maintenant, l'application (dans mon cas Sourcetree) utilise le chemin donné et fonctionne avec Git 1.9.3 :-)
PS: Bien sûr, vous devez ajuster l'entrée Chemin d'accès à vos besoins spécifiques.
la source
Info.plist
fichier de l'application, l'application ne se charge pas:LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Slack.app.
Bien que les réponses ici ne soient pas "erronées", j'en ajouterai une autre: ne modifiez jamais les variables d'environnement sous OS X qui affectent "tous les processus", ou même, en dehors du shell, pour tous les processus exécutés de manière interactive par un utilisateur donné.
D'après mon expérience, les changements globaux des variables d'environnement comme PATH pour tous les processus sont encore plus susceptibles de casser les choses sur OS X que sur Windows. La raison en est que de nombreuses applications OS X et autres logiciels (y compris, peut-être en particulier, les composants du système d'exploitation lui-même) s'appuient sur les outils de ligne de commande UNIX sous le capot et supposent le comportement des versions de ces outils fournies avec le système, et n'utilisez pas nécessairement des chemins absolus pour ce faire (des commentaires similaires s'appliquent aux bibliothèques chargées dynamiquement et aux variables d'environnement DYLD_ *). Considérez, par exemple, que les réponses les mieux notées à diverses questions de débordement de pile concernant le remplacement des versions fournies par OS X d'interprètes comme Python et Ruby disent généralement «ne faites pas cela».
OS X n'est vraiment pas différent des autres systèmes d'exploitation de type UNIX (par exemple, Linux, FreeBSD et Solaris) à cet égard; la raison la plus probable pour laquelle Apple ne fournit pas un moyen facile de le faire est qu'il casse les choses . Dans la mesure où Windows n'est pas aussi sujet à ces problèmes, cela est dû à deux choses: (1) les logiciels Windows n'ont pas tendance à s'appuyer sur les outils de ligne de commande dans la mesure où les logiciels UNIX le font, et (2) Microsoft a eu un historique si complet de "l'enfer des DLL" et des problèmes de sécurité causés par des changements qui affectent tous les processus qu'ils ont changé le comportement du chargement dynamique dans les versions plus récentes de Windows pour limiter l'impact des options de configuration "globales" comme PATH.
"Lame" ou non, vous aurez un système beaucoup plus stable si vous limitez ces modifications à des portées plus petites.
la source
Parfois, toutes les réponses précédentes ne fonctionnent tout simplement pas. Si vous voulez avoir accès à une variable système (comme
M2_HOME
) dans Eclipse ou dans IntelliJ IDEA, la seule chose qui fonctionne pour moi dans ce cas est:Modifiez d'abord (étape 1)
/etc/launchd.conf
pour contenir une ligne comme celle-ci: "valeur VAR setenv" puis (étape 2) redémarrez.La simple modification de .bash_profile ne fonctionnera pas car sous OS X les applications ne sont pas démarrées comme dans les autres Unix; ils n'héritent pas des variables shell du parent. Toutes les autres modifications ne fonctionneront pas pour une raison qui m'est inconnue. Peut-être que quelqu'un d'autre peut clarifier cela.
la source
Après avoir poursuivi le volet des préférences des variables d'environnement et découvert que le lien est rompu et qu'une recherche sur le site d'Apple semble indiquer qu'ils l'ont oublié ... J'ai recommencé sur la piste du processus de lancement insaisissable.
Sur mon système (Mac OS X 10.6.8), il semble que les variables définies dans environment.plist sont exportées de manière fiable vers des applications lancées à partir de Spotlight (via launchd). Mon problème est que ces variables ne sont pas exportées vers de nouvelles sessions bash dans Terminal. C'est-à-dire que j'ai le problème opposé tel qu'il est décrit ici.
REMARQUE: environment.plist ressemble à JSON, pas XML, comme décrit précédemment
J'ai pu obtenir des applications Spotlight pour voir les vars en modifiant ~ / MacOSX / environment.plist et j'ai pu forcer les mêmes vars dans une nouvelle session Terminal en ajoutant ce qui suit à mon fichier .profile:
la source
man launchd
,man launchctl
etman launchd.conf
dans une fenêtre de terminal. Glad Apple maintient les pages de manuel à jour, même si la bibliothèque des développeurs Mac est un peu en retard.Tous les fichiers du Bash -
~/.bashrc
,~/.bash_profile
,~/.profile
. Il existe également une sorte de fichier étrange nommé~/.MacOSX/environment.plist
pour les variables d'environnement dans les applications GUI.la source
Tout comme la réponse de Matt Curtis, j'ai défini des variables d'environnement via launchctl, mais je l'enveloppe dans une fonction appelée export, de sorte que chaque fois que j'exporte une variable comme d'habitude dans mon .bash_profile, elle est également définie par launchctl. Voici ce que je fais:
Mon .bash_profile se compose uniquement d'une ligne, (ce n'est qu'une préférence personnelle.)
Mon .bashrc a ceci:
Ce qui précède surchargera l'export Bash intégré et exportera tout normalement (vous remarquerez que j'exporte "export" avec lui!), Puis les définir correctement pour les environnements d'application OS X via launchctl, que vous utilisiez l'un des éléments suivants:
De cette façon, je n'ai pas à envoyer chaque variable à launchctl à chaque fois, et je peux simplement configurer mon .bash_profile / .bashrc comme je le souhaite. Ouvrez une fenêtre de terminal, consultez vos variables d'environnement qui vous intéressent
launchctl getenv myVar
, changez quelque chose dans votre .bash_profile / .bashrc, fermez la fenêtre de terminal et rouvrez-la, vérifiez à nouveau la variable avec launchctl, et voilá, c'est changé.Encore une fois, comme les autres solutions pour le monde post-Mountain Lion, pour que de nouvelles variables d'environnement soient disponibles pour les applications, vous devez les lancer ou les relancer après le changement.
la source
Voici un moyen très simple de faire ce que vous voulez. Dans mon cas, Gradle fonctionnait (pour Android Studio).
Exécutez la commande suivante:
sudo nano /etc/paths
ousudo vim /etc/paths
Entrez votre mot de passe lorsque vous y êtes invité.
Ouvrez une nouvelle fenêtre de terminal puis tapez:
echo $PATH
Vous devriez voir le nouveau chemin ajouté à la fin du CHEMIN.
J'ai obtenu ces détails de ce post:
Ajouter au PATH sur Mac OS X 10.8 Mountain Lion et plus
la source
Je pense que l'OP recherche une solution simple, semblable à Windows.
Voici:
http://www.apple.com/downloads/macosx/system_disk_utilities/environmentvariablepreferencepane.html
la source
Pour être concis et clair sur la destination de chaque fichier
~/.profile
provient de chaque lancement de Terminal.app~/.bashrc
est l'endroit où "traditionnellement" toutes les déclarations d'exportation pour l'environnement Bash sont définies/etc/paths
est le fichier principal sous Mac OS qui contient la liste des chemins par défaut pour la construction de la variable d'environnement PATH pour tous les utilisateurs/etc/paths.d/
contient des fichiers contenant des chemins de recherche supplémentairesLes programmes non terminaux n'héritent pas des variables PATH et MANPATH à l'échelle du système que votre terminal fait! Pour définir l'environnement pour tous les processus lancés par un utilisateur spécifique, rendant ainsi les variables d'environnement disponibles pour les applications GUI Mac OS X, ces variables doivent être définies dans votre
~/.MacOSX/environment.plist
(Apple Technical Q&A QA1067)Utilisez la ligne de commande suivante pour synchroniser votre
environment.plist
avec/etc/paths
:la source
/etc/launchd.conf n'est pas utilisé sous OS X v10.10 (Yosemite), OS X v10.11 (El Capitan), macOS v10.12 (Sierra) ou macOS v10.13 (High Sierra).
Depuis la
launchctl
page de manuel:La méthode décrite dans cette réponse Ask Different fonctionne pour moi (après un redémarrage): les applications lancées à partir du Dock ou de Spotlight héritent des variables d'environnement que j'ai définies
~/Library/LaunchAgents/my.startup.plist
. (Dans mon cas, je devais définirLANG
, pouren_US.UTF-8
, un plugin Sublime Text.)la source
La
$PATH
variable est également soumise àpath_helper
, qui à son tour utilise le/etc/paths
fichier et les fichiers dans/etc/paths.d
.Une description plus approfondie peut être trouvée dans PATH et autres problèmes d'environnement dans Leopard (2008-11)
la source
C'est simple:
Editez ~ / .profile et mettez vos variables comme suit
Dans le fichier mis:
Enregistrer (: wq)
Redémarrez le terminal (quittez-le et rouvrez-le)
Assurez-vous que tout va bien:
la source
Pour une modification d'un seul utilisateur, utilisez
~/.profile
celles que vous avez répertoriées. Le lien suivant explique quand les différents fichiers sont lus par Bash.http://telin.ugent.be/~slippens/drupal/bashrc_and_others
Si vous souhaitez définir la variable d'environnement pour les applications GUI, vous avez besoin du fichier ~ / .MacOSX / environment.plist
la source
Eh bien, je ne suis pas sûr des fichiers
/etc/paths
et~/.MacOSX/environment.plist
. Ce sont nouveaux.Mais avec Bash, vous devez savoir qu'il
.bashrc
est exécuté à chaque nouvelle invocation de shell et.bash_profile
n'est exécuté qu'une seule fois au démarrage.Je ne sais pas combien de fois c'est avec Mac OS X. Je pense que la distinction s'est rompue avec le système de fenêtres qui lance tout.
Personnellement, j'élimine la confusion en créant un
.bashrc
fichier avec tout ce dont j'ai besoin, puis je fais:la source
Une chose à noter en plus des approches suggérées est que, dans OS X 10.5 (Leopard) au moins, les variables définies dans
launchd.conf
seront fusionnées avec les paramètres définis dans.profile
. Je suppose que cela est probablement valable pour les paramètres~/.MacOSX/environment.plist
, mais je n'ai pas vérifié.la source
Configurer votre variable d'environnement PATH sur Mac OS
Ouvrez le programme Terminal (il se trouve dans votre dossier Applications / Utilitaires par défaut). Exécutez la commande suivante
Cela ouvrira le fichier dans votre éditeur de texte par défaut.
Pour le SDK Android comme exemple:
Vous devez ajouter le chemin d'accès à votre répertoire d'outils et de plateforme SDK Android. Dans mon exemple, j'utiliserai "/ Development / android-sdk-macosx" comme répertoire d'installation du SDK. Ajoutez la ligne suivante:
Enregistrez le fichier et quittez l'éditeur de texte. Exécutez votre .bash_profile pour mettre à jour votre CHEMIN:
Maintenant, chaque fois que vous ouvrez le programme Terminal, votre PATH comprendra le SDK Android.
la source
Je viens de le faire très facilement et rapidement. Créez d'abord un ~ / .bash_profile à partir du terminal:
puis
ajouter
enregistrez la documentation et vous avez terminé.
la source
C'est assez simple. Modifier le fichier
.profile
(vi, nano , Sublime Text ou autre éditeur de texte). Vous pouvez le trouver dans le~/
répertoire (répertoire utilisateur) et définir comme ceci:Exemple avec Java home:
Enregistrez-le et revenez au terminal.
Vous pouvez le recharger avec:
Ou fermez et ouvrez la fenêtre de votre terminal.
la source
Il existe deux types d'obus en jeu ici.
Il est important de comprendre ici qu'avec Bash, le fichier
.bashrc
n'est lu que par un shell à la fois interactif et non connecté, et vous constaterez que les gens se chargent souvent.bashrc
dans.bash_profile
de surmonter cette limitation.Maintenant que vous avez la compréhension de base, passons à la façon dont je vous conseillerais de la configurer.
.bash_file:
la source
Coquilles de connexion
Le shell exécute d'abord les commandes dans le fichier
/etc/profile
. Un utilisateur travaillant avec des privilèges root peut configurer ce fichier pour établir des caractéristiques par défaut à l'échelle du système pour les utilisateurs exécutant Bash.Ensuite , les regards de coquille pour
~/.bash_profile
,~/.bash_login
et~/.profile
(~ / est la main court pour votre répertoire personnel), dans cet ordre, l' exécution des commandes dans le premier de ces fichiers qu'il trouve. Vous pouvez placer des commandes dans l'un de ces fichiers pour remplacer les valeurs par défaut définies dans/etc/profile
. Un shell exécuté sur un terminal virtuel n'exécute pas de commandes dans ces fichiers.Lorsque vous vous déconnectez, bash exécute les commandes du
~/.bash_logout
fichier. Ce fichier contient souvent des commandes de nettoyage après une session, telles que celles qui suppriment des fichiers temporaires.Coques non connectées interactives
Bien qu'ils ne soient pas appelés directement par bash, de nombreux
~/.bashrc
fichiers appellent/etc/bashrc
. Cette configuration permet à un utilisateur travaillant avec des privilèges root d'établir des caractéristiques par défaut à l'échelle du système pour les shells bash sans connexion.Un shell non connecté interactif exécute des commandes dans le
~/.bashrc
fichier. En règle générale, un fichier de démarrage pour un shell de connexion, tel que.bash_profile
, exécute ce fichier, de sorte que les shells de connexion et non-login exécutent les commandes dans.bashrc
.Étant donné que les commandes
.bashrc
peuvent être exécutées plusieurs fois et que les sous-coquilles héritent des variables exportées, il est judicieux de placer des commandes qui s'ajoutent aux variables existantes dans le.bash_profile
fichier.la source
Toute la magie sur iOS ne va qu'avec l'utilisation
source
avec le fichier, où vous exportez vos variables d'environnement.Par exemple:
Vous pouvez créer un fichier comme celui-ci:
Enregistrez ce fichier sous
bimbom.env
et faitessource ./bimbom.ev
. Voilá, vous avez obtenu vos variables d'environnement.Vérifiez-les avec:
la source
Pour Bash, essayez d'ajouter vos variables d'environnement au fichier
/etc/profile
pour les rendre disponibles pour tous les utilisateurs. Pas besoin de redémarrer, il suffit de démarrer une nouvelle session Terminal.la source