Comment définir les variables d'environnement du système sous OS X Mavericks ?

Hmm... A partir de Mac OS X 10.10.5 et probablement avant, man -s5 launchd.conf nous dit : " launchd.conf is no longer respected by the system. " J'ai trop de choses à faire en ce moment pour mettre une variable fictive dans le fichier et redémarrer pour voir si cela fonctionne vraiment ou pas après tout, mais la documentation dit que cela ne devrait pas fonctionner.

Je suis presque sûr que non. Faites man launchctl et vous verrez : " The /etc/launchd.conf file is no longer consulted for subcommands to run during early boot time; this functionality was removed for security considerations. "

Ce que vous peut consiste à placer toutes les variables d'environnement que vous souhaitez rendre globales dans un fichier, peut-être appelé environment en accord avec Linux, ou (au cas où Apple déciderait d'en faire quelque chose plus tard - on ne sait jamais) environment.conf comme je l'ai fait, puis en faire la source via /etc/profile :

if [ -f /etc/environment.conf ]; then
   source /etc/environment.conf
fi

ou, si vous préférez le format compact :

if [ -f /etc/environment.conf ]; then . /etc/environment.conf; fi

Si vous utilisez un autre shell que bash, y il utilise la même syntaxe de définition de variables que bash (ainsi que zsh, je pense), vous devrez également obtenir ce fichier à partir du fichier rc du système de cet interpréteur de commandes (par ex. /etc/zshrc ). Si vous utilisez un interpréteur de commandes qui utilise une syntaxe différente, par exemple tcsh, vous devrez soit maintenir un fichier similaire pour cet interpréteur de commandes et le sourcer à partir du fichier rc du système de l'interpréteur de commandes (par ex. /etc/csh.cshrc pour tcsh), ou mieux encore créer un script qui le génère automatiquement, de sorte que vous n'ayez qu'à éditer un seul fichier pour ajouter/changer les variables. Ce n'est pas l'endroit pour un tel tutoriel ; quelques secondes sur Google ont permis de trouver comment convertir les exportations de variables [t]csh en syntaxe bash, à l'adresse suivante https://stackoverflow.com/questions/2710790/how-to-source-a-csh-script-en-base-pour-établir-les-enviroments donc il y a probablement quelque chose de disponible pour aller dans l'autre sens.

D'après mon expérience, Mac OS X s'éloigne de plus en plus du comportement prévisible des fichiers rc. Depuis au moins 10.8, il ne semble plus charger /etc/rc.common , /etc/rc.conf o /etc/rc.<anything> et (depuis au moins 10.9) il ne charge pas non plus /etc/bash.bashrc pour les shells interactifs sans login (ce qu'il devrait certainement faire, tout comme il charge ~/.bashrc pour eux, toujours, à partir de 10.10). Mais encore une fois, j'ai Fink, MacPorts et Homebrew qui installent des trucs, alors peut-être que l'un d'eux interfère avec le comportement par défaut de dotfile. YMMV.

Je sais que cette question portait sur MacOS Mavericks. (qui, je crois, était par défaut /bin/bash pour son enveloppe) . Je suis arrivé à ce post en cherchant une réponse sur MacOS Monterey (qui a pour valeur par défaut /bin/zsh ) .

Passage à bash en exécutant /bin/bash a fourni un message utile qui a fini par me conduire dans la bonne direction :

Le shell interactif par défaut est maintenant zsh.
Pour mettre à jour votre compte pour utiliser zsh, veuillez exécuter chsh -s /bin/zsh .
Pour plus de détails, veuillez consulter https://support.apple.com/kb/HT208050 .

Profil de la coquille

J'avais l'habitude de pouvoir appliquer des configurations globales de l'interpréteur de commandes à l'aide de la commande /etc/profile mais j'ai appris que zsh utilise ses propres /etc/zprofile . Modification de la /etc/zprofile était la solution que je recherchais.

Pour ma configuration, j'ai suivi l'approche habituelle consistant à créer un fichier /etc/profile.d contenant plusieurs .sh des fichiers. J'ai ensuite ajouté les éléments suivants à mon /etc/zprofile pour obtenir les fichiers :

# Profile Scripts
for PROFILE in $(ls /etc/profile.d/*.sh); do
  source "${PROFILE}"
done

SSH

J'ai fait un test avec ssh à partir d'un autre ordinateur local pour vérifier les préoccupations des variables d'environnement. Cette approche semblait donner les variables d'environnement définies dans le fichier /etc/profile.d scripts sans problème.