Définition de variables d'environnement sur OS X

850

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).

Paul Wicks
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.
Hong

Réponses:

653

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 .

  1. Ouvrez une invite de terminal

  2. Type sudo vi /etc/launchd.conf(remarque: ce fichier n'existe peut-être pas encore)

  3. Mettez du contenu comme le suivant dans le fichier

    # Set environment variables here so they are available globally to all apps
    # (and Terminal), including those launched via Spotlight.
    #
    # After editing this file run the following command from the terminal to update
    # environment variables globally without needing to reboot.
    # NOTE: You will still need to restart the relevant application (including
    # Terminal) to pick up the changes!
    # grep -E "^setenv" /etc/launchd.conf | xargs -t -L 1 launchctl
    #
    # See http://www.digitaledgesw.com/node/31
    # and http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x/
    #
    # Note that you must hardcode the paths below, don't use environment variables.
    # You also need to surround multiple values in quotes, see MAVEN_OPTS example below.
    #
    setenv JAVA_VERSION 1.6
    setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
    setenv GROOVY_HOME /Applications/Dev/groovy
    setenv GRAILS_HOME /Applications/Dev/grails
    setenv NEXUS_HOME /Applications/Dev/nexus/nexus-webapp
    setenv JRUBY_HOME /Applications/Dev/jruby
    
    setenv ANT_HOME /Applications/Dev/apache-ant
    setenv ANT_OPTS -Xmx512M
    
    setenv MAVEN_OPTS "-Xmx1024M -XX:MaxPermSize=512m"
    setenv M2_HOME /Applications/Dev/apache-maven
    
    setenv JMETER_HOME /Applications/Dev/jakarta-jmeter
  4. Enregistrez vos modifications dans vi et redémarrez votre Mac. Ou utilisez la commande grep/ xargsqui est indiquée dans le commentaire de code ci-dessus.

  5. Prouvez que vos variables fonctionnent en ouvrant une fenêtre de terminal et en tapant exportet 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.

Matthew McCullough
la source
3
Je dis que la réponse acceptée (environnement.pliste) n'a pas réussi pour moi. J'ai utilisé avec succès l'approche launchd.conf sur 10.5 et 10.6 sur quatre machines.
Matthew McCullough
54
Est - il possible de le faire sans faire un redémarrage du système ?
sorin
40
La limitation mentionnée ci-dessus s'applique à MacOS X 10.5. Cependant, MacOS X 10.6 n'a plus cette limitation et la définition des valeurs dans environment.plist fonctionne bien même pour les applications lancées via Spotlight. La réponse choisie est donc correcte pour Snow Leopard ;-)
Louis Jacomet
5
Le réglage launchd.confest à 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/…
Matt Curtis
23
Il y a plusieurs problèmes avec l'approche de lancement présentée. La plupart sont spécifiques à la variable d'environnement PATH, mais le demandeur a mentionné spécifiquement PATH. 1) les éléments de launchd.conf ne sont pas appliqués dans des shells interactifs tels que ssh dans le système. 2) la ligne "setenv PATH / testdir" s'ajoute au PATH dans Terminal.app, mais supprime tous les autres éléments PATH dans les environnements des applications OS X. 3) Faire "setenv PATH $ {PATH}: / testdir" dans /etc/launchd.conf ne développe pas correctement $ PATH existant 4) launchd.conf s'applique à tous les utilisateurs, au lieu d'un seul. Non pas que j'aie une meilleure solution.
NoahR
257

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:

launchctl setenv PATH /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

Ou si vous souhaitez configurer votre chemin dans .bashrcou similaire, faites-le en miroir dans launchd:

PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
launchctl setenv PATH $PATH

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:$PATHfor 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.confcomme suit :

setenv PATH /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

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!)

egrep -v '^\s*#' /etc/launchd.conf | launchctl

Vous pouvez en savoir plus sur launchctlet comment il se charge launchd.confavec la commande man launchctl.

Matt Curtis
la source
2
Très sympa! L'avantage d'utiliser environment.plist semble cependant être que OS X respecte le contenu de ces fichiers sans avoir à démarrer en premier un terminal. Quoi qu'il en soit, je pense que votre réponse s'est principalement concentrée sur l'évitement de la nécessité d'un redémarrage, alors merci pour cela.
fotNelton
2
@kapuzineralex Oui, cela évite un redémarrage, il modifie également l'environnement pour les programmes démarrés à partir de Spotlight, ce qui environment.plistn'est pas le cas.
Matt Curtis
2
Définir l'environnement de cette manière n'a fonctionné pour moi que jusqu'à ce que je redémarre. La variable d'environnement n'a pas duré après le redémarrage du mac. La réponse de Matthew a parfaitement fonctionné pour moi.
Shamal Karunarathne
8
@Shamal: J'ai attribué la mention +1 à votre commentaire, mais gardez à l'esprit que la réponse de Matthew nécessite un redémarrage, alors que je vous indique la bonne façon de le changer sans redémarrage. Si vous voulez les deux, je vous suggère de mettre vos paramètres de chemin dans launchd.conf (afin qu'ils persistent pendant les redémarrages), puis d'utiliser un script avec quelque chose comme ceci "source /etc/launchctl.conf; launchctl setenv PATH $ PATH", donc vous pouvez également "rafraîchir" lorsque vous ne souhaitez pas redémarrer.
Matt Curtis
5
@MattCurtis Pourriez-vous s'il vous plaît modifier votre réponse directement pour qu'il soit clair que même si aucun redémarrage n'est requis, les modifications seront réellement perdues après un redémarrage? En outre, la bonne façon d'appliquer les changements de etc/launchd.confavant un redémarrage serait d'utiliser l'approche @ réponse de MatthewMcCullough: egrep "^setenv\ " /etc/launchd.conf | xargs -t -L 1 launchctl.
mklement0
106

Jusqu'à OS X v10.7 (Lion) inclus, vous pouvez les définir dans:

~/.MacOSX/environment.plist

Voir:

Pour PATH dans le terminal, vous devriez pouvoir le configurer .bash_profileou .profile(vous devrez probablement le créer cependant)

Pour OS X v10.8 (Mountain Lion) et au-delà, vous devez utiliser launchdetlaunchctl .

tim_yates
la source
4
C'est seulement si vous vous attendez à ce qu'ils soient utilisés par des applications graphiques. Étant donné que ceux-ci n'utilisent généralement pas de variables d'environnement, ce n'est pas un très bon endroit pour les définir.
Chris Hanson
18
Il existe de très bons exemples d'applications graphiques qui utilisent des variables d'environnement. IntelliJ, par exemple, aime pouvoir voir M2_HOME pour savoir où vit Maven. Pour lui faire voir la variable, vous devrez la placer dans /etc/launchd.conf au lieu de environment.plist.
Matthew McCullough
3
Pour référence: l'utilisation preferences.plistn'était pas idéale avec OS X 10.5 car à cette époque preferences.plistn'é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.6 environment.plistfonctionne comme il se doit.
Janus
16
Cela ne s'applique plus à OSX 10.8 apple.stackexchange.com/questions/57385/…
thatsmydoing
1
@tim_yates Pourriez-vous s'il vous plaît modifier la première ligne de votre réponse pour lire "jusqu'à et y compris Lion (10. * 7 *)", étant donné que c'est ce qui est correct? J'ai essayé de faire ce montage sur l'original, ambigu "Up to Mountain Lion", et les critiques l'ont bâclé.
mklement0
67

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_profilecomme dans l'extrait de code suivant:

export JAVA_HOME="$(/usr/libexec/java_home -v 1.8)"
export GOPATH="$HOME/go"
export PATH="$PATH:/usr/local/opt/go/libexec/bin:$GOPATH/bin"
export PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
export MANPATH="/usr/local/opt/coreutils/libexec/gnuman:$MANPATH"

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 plistsuffixe (par exemple nommé osx-env-sync.plist) dans le ~/Library/LaunchAgents/répertoire avec le contenu suivant:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>osx-env-sync</string>
  <key>ProgramArguments</key>
  <array>
    <string>bash</string>
    <string>-l</string>
    <string>-c</string>
    <string>
      $HOME/.osx-env-sync.sh
    </string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

-lle 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_profilesoit originaire avant l'exécution de ce script.

Maintenant, le script shell. Créez-le ~/.osx-env-sync.shavec le contenu suivant:

grep export $HOME/.bash_profile | while IFS=' =' read ignoreexport envvar ignorevalue; do
  launchctl setenv ${envvar} ${!envvar}
done

Assurez-vous que le script shell est exécutable:

chmod +x ~/.osx-env-sync.sh

Maintenant, chargez l'agent de lancement pour la session en cours:

launchctl load ~/Library/LaunchAgents/osx-env-sync.plist

(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_profileenvironnement, la réexécution de la launchctl 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:

launchctl unload ~/Library/LaunchAgents/osx-env-sync.plist
launchctl load ~/Library/LaunchAgents/osx-env-sync.plist

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).

Ersin Er
la source
Fonctionne bien. Un peu inquiet si cela devenait populaire s'il s'agissait d'une faille de sécurité
Warren P
3
Cette solution était la seule que je pouvais faire fonctionner correctement. Excellentes solutions. Je ne comprends pas pourquoi cela devrait être si dur sur mac ...
JohnyTex
2
Cela ne fonctionne malheureusement pas sur El Capitan. Votre commentaire de github.com/ersiner/osx-env-sync/issues/1#issuecomment-169803508 explique bien le problème.
mgol du
1
Donc, cette solution ne fonctionne pas, /etc/launchd.conf n'a aucun effet, Node.js installe son binaire dans / usr / local / bin et ce chemin n'est pas dans PATH pour les applications GUI. Par conséquent, les hooks Git utilisant Node ne fonctionnent pas du tout dans les applications GUI Git comme SourceTree dans El Capitan. C'est terrible.
mgol
1
Le problème concerne uniquement la variable PATH. J'espère que nous pourrons bientôt trouver une solution.
Ersin Er
54
  1. Faire:

    vim ~/.bash_profile

    Le fichier peut ne pas exister (sinon, vous pouvez simplement le créer).

  2. Tapez-le et enregistrez le fichier:

    export PATH=$PATH:YOUR_PATH_HERE
  3. Courir

    source ~/.bash_profile
WoooHaaaa
la source
+1 exportétait ce que j'allais suggérer, car BASH ne prend pas en chargesetenv
vol7ron
Fonctionne pour l'instant. Tout cela semble beaucoup plus compliqué que je ne le pensais. Il faudra consacrer plus de temps à tout cela plus tard. Merci.
Ruto Collins
34

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

#!/bin/bash
bash -l -c "/Applications/Emacs.app/Contents/MacOS/Emacs --batch -l ~/lib/emacs/elisp/macosx/environment-support.el -f generate-environment"

Fonction Emacs lisp: ~/lib/emacs/elisp/macosx/envionment-support.el

;;; Provide support for the environment on Mac OS X

(defun generate-environment ()
  "Dump the current environment into the ~/.MacOSX/environment.plist file."
  ;; The system environment is found in the global variable:
  ;; 'initial-environment' as a list of "KEY=VALUE" pairs.
  (let ((list initial-environment)
        pair start command key value)
    ;; clear out the current environment settings
    (find-file "~/.MacOSX/environment.plist")
    (goto-char (point-min))
    (setq start (search-forward "<dict>\n"))
    (search-forward "</dict>")
    (beginning-of-line)
    (delete-region start (point))
    (while list
      (setq pair (split-string (car list) "=")
            list (cdr list))
      (setq key (nth 0 pair)
            value (nth 1 pair))
      (insert "  <key>" key "</key>\n")
      (insert "  <string>" value "</string>\n")

      ;; Enable this variable in launchd
      (setq command (format "launchctl setenv %s \"%s\"" key value))
      (shell-command command))
    ;; Save the buffer.
    (save-buffer)))

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_profileplate-forme de contenu indépendante et de mettre le paramètre de l' launchdenvironnement (une installation Mac uniquement) dans un script distinct .

pajato0
la source
20
Sensationnel. Je ne dis pas que cela ne fonctionnera pas, mais ... Je suis juste consterné par la complexité requise pour obtenir un environnement cohérent sur OS X.
offby1
2
Cela fonctionne le mieux de toutes les solutions que j'ai vues pour 10.9. Le seul défaut est que, puisque les éléments de connexion s'exécutent dans un ordre indéterminé, si Emacs (par exemple) est lancé à la connexion (car il était ouvert à la déconnexion, par exemple), il n'aura pas nécessairement les variables d'environnement à moins que vous ne le redémarriez , car il est lancé avant votre script.
telotortium
22

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:

EnvPane est un volet de préférences pour Mac OS X 10.8 (Mountain Lion) qui vous permet de définir des variables d'environnement pour tous les programmes dans les sessions graphiques et de terminal. Non seulement il restaure la prise en charge de ~ / .MacOSX / environment.plist dans Mountain Lion, mais il publie également vos modifications dans l'environnement immédiatement, sans avoir besoin de se déconnecter et de se reconnecter. <SNIP> EnvPane inclut (et installe automatiquement) un agent launchd qui s'exécute 1) tôt après la connexion et 2) chaque fois que le ~ / .MacOSX / environment.plist change. L'agent lit ~ / .MacOSX / environment.plist et exporte les variables d'environnement de ce fichier vers l'instance launchd de l'utilisateur actuel via la même API utilisée par launchctl setenv et launchctl unsetenv.

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»).

Big Rich
la source
2
EnvPane ne peut pas définir PATH pour le moment. Pour plus de détails, voir mon rapport de bug: github.com/hschmidt/EnvPane/issues/5
Uwe Günther
Je ♥ ️ cette chose .. Seul inconvénient .. dont je pense que TOUTE solution sera victime .. est de devoir redémarrer un processus pour hériter du nouvel "environnement". Wonk wonk.
Alex Gray
2
@sorin: Pouvez-vous ouvrir un problème sur le site GitHub avec une description du problème que vous rencontrez? EnvPane fonctionne pour moi le 10.10. Avertissement: je suis l'auteur d'EnvPane.
Hannes
17

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 systemet pour l' useroption de launchctl 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/binn'est plus accessible en écriture).

J'ai lu à plusieurs endroits que l'utilisation launchctl setenv PATH <new path>de la définition de la PATHvariable 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 de PATHdéfinir les applications non lancées à partir du shell :

sudo launchctl config user path <new path>

Cette option est documentée dans la page de manuel launchctl:

système de configuration | valeur du paramètre utilisateur

Définit les informations de configuration persistantes pour les domaines launchd (8). Seuls le domaine système et les domaines utilisateur peuvent être configurés. L'emplacement du stockage persistant est un détail d'implémentation et les modifications apportées à ce stockage ne doivent être effectuées que par le biais de cette sous-commande. Un redémarrage est requis pour que les modifications apportées via cette sous-commande prennent effet.

[...]

chemin

Définit la variable d'environnement PATH pour tous les services du domaine cible sur la valeur de chaîne. La valeur de la chaîne doit être conforme au format décrit pour la variable d'environnement PATH dans environ (7). Notez que si un service spécifie son propre PATH, la variable d'environnement spécifique au service aura priorité.

REMARQUE: cette fonctionnalité ne peut pas être utilisée pour définir des variables d'environnement générales pour tous les services du domaine. Il est intentionnellement limité à la variable d'environnement PATH et rien d'autre pour des raisons de sécurité.

J'ai confirmé que cela fonctionne avec une application GUI démarrée à partir du Finder (qui utilise getenvpour 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.

Max Leske
la source
Ça marche pour moi aussi. sudo launchctl procinfo <gui-pid>montre l' PATHenvironnement nouvellement défini . Mais en sudo 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)
Bossliaw
1
Cela ne semble pas avoir d'effet sur la variable d'environnement PATH des applications qui sont rouvertes à la connexion (qui étaient ouvertes lors de l'arrêt).
Brecht Machiels
Intéressant. Cela signifierait que pour les applications qui seront rouvertes, l'environnement (ou un sous-ensemble de celui-ci) est enregistré.
Max Leske
@MaxLeske Non, les applications rouvertes sont en cours de démarrage avant que la variable d'environnement ne soit modifiée. Donc, ce n'est pas seulement la première fois après l'avoir fait sudo launchctl config user path, que cela se produit (ce que vous semblez supposer?).
Brecht Machiels
1
@ShlomiSchwartz launchctlne pas vous permet de définir des variables d'environnement arbitraires. La PATHvariable est une exception.
Max Leske
17

Sur Mountain Lion tous les /etc/pathset l' /etc/launchd.confédition ne fait aucun effet!

Les forums des développeurs d'Apple disent:

"Modifiez le Info.plist du .app lui-même pour contenir un dictionnaire" LSEnvironment "avec les variables d'environnement souhaitées.

~ / .MacOSX / environment.plist n'est plus pris en charge. "

J'ai donc édité directement l'application Info.plist(clic droit sur "AppName.app" (dans ce cas SourceTree) puis " Show package contents").

Afficher le contenu du paquet

Et j'ai ajouté une nouvelle paire clé / dict appelée:

<key>LSEnvironment</key>
<dict>
     <key>PATH</key>
     <string>/Users/flori/.rvm/gems/ruby-1.9.3-p362/bin:/Users/flori/.rvm/gems/ruby-1.9.3-p362@global/bin:/Users/flori/.rvm/rubies/ruby-1.9.3-p326/bin:/Users/flori/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:</string>
</dict>

(voir: Documentation LaunchServicesKeys sur Apple )

Entrez la description de l'image ici

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.

Flori
la source
3
Cette solution répond à la norme la moins intrusive du système. Merci.
John Vance
@John Vance +1 Tout à fait d'accord, les changements à l'échelle du système sont toujours risqués comme Jason T. Miller l'explique clairement dans sa réponse
rmcsharry
5
Cela n'a aucun effet pour moi à El Capitan. :(
mgol
Sur High Sierra 10.13, si je modifie le Info.plistfichier de l'application, l'application ne se charge pas:LSOpenURLsWithRole() failed with error -10810 for the file /Applications/Slack.app.
kunjbhai
16

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.

Jason T. Miller
la source
1
Dire aux gens de ne pas faire ce qu'ils ont demandé n'est pas une réponse à la question qu'ils ont posée. Empêcher les gens de faire cela, c'est aussi casser des choses. Modus operandi d'Apple.
frabjous
La définition du CHEMIN dans /Applications/App.app/Contents/Info.plist avec la clé LSEnvironment developer.apple.com/library/archive/documentation/General/… pourrait être la solution recommandée actuelle.
Dave X
15

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.confpour 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.

Bruno Ranschaert
la source
5
Les applications démarrées à partir de Spotlight ou par tout autre moyen ont toutes /etc/launchd.conf lues par leur processus parent, ce qui en fait un choix attrayant pour savoir où définir les variables d'environnement visibles dans toutes les applications et tous les shells.
Matthew McCullough
1
Voir ma réponse pour une autre solution, qui évite un redémarrage - stackoverflow.com/questions/135688/…
Matt Curtis
Ma machine MaxOS 10.6 n'a pas le fichier /etc/launchd.conf présent. Est-ce une chose nouvelle ou obsolète à partir de cette version? Ou cette machine est-elle foirée?
peterk
13

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:

eval $(launchctl export)
Russell B
la source
2
Pas si insaisissable: RCenvironnement
Gilimanjaro
Bon conseil sur l'export launchctl. Mais je ne mettrais pas cela tel quel dans .profile. Il remplacera votre $ PATH par un qui n'inclut pas / usr / local / bin. Mais vous pouvez utiliser une expression régulière pour sélectionner les variables qui vous intéressent: `` eval $ (launchctl export | grep '^ my. * =').
mivk
3
Sur ma nouvelle machine Mountain Lion (10.8.2), le fichier environment.plist n'a aucune valeur. Voir la réponse de Matthew pour la bonne piste. Il s'agit du lancement et de l'application de ligne de commande launchctl avec /etc/launchd.conf. Vous pouvez lire vous - même avec man launchd, man launchctlet man launchd.confdans 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.
Russell B
10

Tous les fichiers du Bash - ~/.bashrc, ~/.bash_profile, ~/.profile. Il existe également une sorte de fichier étrange nommé ~/.MacOSX/environment.plistpour les variables d'environnement dans les applications GUI.

John Millikin
la source
10

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:

  1. Mon .bash_profile se compose uniquement d'une ligne, (ce n'est qu'une préférence personnelle.)

    source .bashrc
  2. Mon .bashrc a ceci:

    function export()
    {
        builtin export "$@"
        if [[ ${#@} -eq 1 && "${@//[^=]/}" ]]
        then
            launchctl setenv "${@%%=*}" "${@#*=}"
        elif [[ ! "${@//[^ ]/}" ]]
        then
            launchctl setenv "${@}" "${!@}"
        fi
    }
    
    export -f export
  3. 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:

    export LC_CTYPE=en_US.UTF-8
    # ~$ launchctl getenv LC_CTYPE
    # en_US.UTF-8
    PATH="/usr/local/bin:${PATH}"
    PATH="/usr/local/opt/coreutils/libexec/gnubin:${PATH}"
    export PATH
    # ~$ launchctl getenv PATH
    # /usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
    export CXX_FLAGS="-mmacosx-version-min=10.9"
    # ~$ launchctl getenv CXX_FLAGS
    # -mmacosx-version-min=10.9
  4. 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é.

  5. 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.

courtlandj
la source
1
Réponse utile - merci. Je viens de le mettre à jour car votre solution d'origine ne gérait pas les cas où la valeur de la variable d'environnement que vous définissiez avait des signes égaux (par exemple, CXX_FLAGS = "- mmacosx-version-min = 10.9"
Steve Broberg
@SteveBroberg - juste un changement d'un caractère corrige le regexp Bash sans avoir besoin de sed! (Ne vous méprenez pas, j'aime sed, mais cela fonctionne et est beaucoup plus court.)
courtlandj
1
Je pensais qu'il devait y avoir un meilleur moyen, mais je ne suis pas un gourou bash, et je ne pouvais pas google ce que %%, ## étaient, etc.
Steve Broberg
10

Voici un moyen très simple de faire ce que vous voulez. Dans mon cas, Gradle fonctionnait (pour Android Studio).

  • Ouvrez Terminal.
  • Exécutez la commande suivante:

    sudo nano /etc/paths ou sudo vim /etc/paths

  • Entrez votre mot de passe lorsque vous y êtes invité.

  • Allez au bas du fichier et entrez le chemin que vous souhaitez ajouter.
  • Appuyez sur Control+ Xpour quitter.
  • Entrez «Y» pour enregistrer le tampon modifié.
  • 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

filaire00
la source
7

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émentaires

Les 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.plistavec /etc/paths:

defaults write $HOME/.MacOSX/environment PATH "$(tr '\n' ':' </etc/paths)"
Claudio Floreani
la source
6

/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 launchctlpage de manuel:

/etc/launchd.conf file is no longer consulted for subcommands to run during early boot time;
this functionality was removed for security considerations.

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éfinir LANG, pour en_US.UTF-8, un plugin Sublime Text.)

David
la source
Au redémarrage, existe-t-il un ordre de chargement qui garantit que my.startup.plist aurait été chargé avant le redémarrage des applications de la dernière session?
kunjbhai
3

C'est simple:

Editez ~ / .profile et mettez vos variables comme suit

$ vim ~ / .profile

Dans le fichier mis:

MY_ENV_VAR = valeur

  1. Enregistrer (: wq)

  2. Redémarrez le terminal (quittez-le et rouvrez-le)

  3. Assurez-vous que tout va bien:

$ echo $ MY_ENV_VAR

$ value


Fernando Martínez
la source
3

Pour une modification d'un seul utilisateur, utilisez ~/.profilecelles 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

mmaibaum
la source
3

Eh bien, je ne suis pas sûr des fichiers /etc/pathset ~/.MacOSX/environment.plist. Ce sont nouveaux.

Mais avec Bash, vous devez savoir qu'il .bashrcest exécuté à chaque nouvelle invocation de shell et .bash_profilen'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 .bashrcfichier avec tout ce dont j'ai besoin, puis je fais:

ln -s .bashrc .bash_profile
mike511
la source
3

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.confseront 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é.

MiB
la source
3

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

touch ~/.bash_profile; open ~/.bash_profile

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:

export PATH=${PATH}:/Development/android-sdk-macosx/platform-tools:/Development/android-sdk-macosx/tools

Enregistrez le fichier et quittez l'éditeur de texte. Exécutez votre .bash_profile pour mettre à jour votre CHEMIN:

source ~/.bash_profile

Maintenant, chaque fois que vous ouvrez le programme Terminal, votre PATH comprendra le SDK Android.

Charaf JRA
la source
3

Je viens de le faire très facilement et rapidement. Créez d'abord un ~ / .bash_profile à partir du terminal:

touch .bash_profile

puis

open -a TextEdit.app .bash_profile

ajouter

export TOMCAT_HOME=/Library/Tomcat/Home

enregistrez la documentation et vous avez terminé.

CodeOverRide
la source
Perfecto. J'ai suivi les étapes pour JAVA_HOME, juste ajouté l'exportation JAVA_HOME = / Library / Java / JavaVirtualMachines / jdk1.8.0_201.jdk / Contents / Home et un vrai succès rapide!
NarendraC
Super @NarendraC!
CodeOverRide
2

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:

export MY_VAR=[your value here]

Exemple avec Java home:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/current

Enregistrez-le et revenez au terminal.

Vous pouvez le recharger avec:

source .profile

Ou fermez et ouvrez la fenêtre de votre terminal.

francois.robert
la source
2

Il existe deux types d'obus en jeu ici.

  • Non-connexion: .bashrc est rechargé à chaque fois que vous démarrez une nouvelle copie de Bash
  • Login: le .profile n'est chargé que lorsque vous vous connectez ou que vous dites explicitement à Bash de le charger et de l'utiliser comme shell de connexion.

Il est important de comprendre ici qu'avec Bash, le fichier .bashrcn'est lu que par un shell à la fois interactif et non connecté, et vous constaterez que les gens se chargent souvent .bashrcdans.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.

  • .profile: créez-le inexistant. Mettez votre configuration PATH là-dedans.
  • .bashrc: crée s'il n'existe pas. Mettez-y tous vos alias et méthodes personnalisées.
  • .bash_profile: crée s'il n'existe pas. Mettez ce qui suit là-dedans.

.bash_file:

#!/bin/bash
source ~/.profile # Get the PATH settings
source ~/.bashrc  # Get Aliases and Functions
#
ZOXIS
la source
2

Coquilles de connexion

/etc/profile

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.

.bash_profile
.bash_login
.profile

Ensuite , les regards de coquille pour ~/.bash_profile, ~/.bash_loginet ~/.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.

.bash_logout

Lorsque vous vous déconnectez, bash exécute les commandes du ~/.bash_logoutfichier. 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

/etc/bashrc

Bien qu'ils ne soient pas appelés directement par bash, de nombreux ~/.bashrcfichiers 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.

.bashrc

Un shell non connecté interactif exécute des commandes dans le ~/.bashrcfichier. 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 .bashrcpeuvent ê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_profilefichier.

Koray Tugay
la source
2

Toute la magie sur iOS ne va qu'avec l'utilisation sourceavec le fichier, où vous exportez vos variables d'environnement.

Par exemple:

Vous pouvez créer un fichier comme celui-ci:

export bim=fooo
export bom=bar

Enregistrez ce fichier sous bimbom.envet faites source ./bimbom.ev. Voilá, vous avez obtenu vos variables d'environnement.

Vérifiez-les avec:

echo $bim
suther
la source
1

Pour Bash, essayez d'ajouter vos variables d'environnement au fichier /etc/profilepour les rendre disponibles pour tous les utilisateurs. Pas besoin de redémarrer, il suffit de démarrer une nouvelle session Terminal.

Rabi
la source