Définition de PATH par rapport à l'export de PATH dans ~ / .bash_profile

Quelle est la différence et quel est le meilleur à utiliser lors de la personnalisation de mon profil bash? La documentation sur la command d' export est rare, car il s'agit d'un cmd embedded.

Extrait de la version 1 de mon ~ / .bash_profile:

 #PATH export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$HOME/bin #add Homebrew's sbin to PATH export PATH=/usr/local/sbin:$PATH 

Sortie de: echo $PATH /usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/njboot/bin

Extrait de la version 2:

 #PATH PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$HOME/bin #add Homebrew's sbin to PATH export PATH=/usr/local/sbin:$PATH 

La sortie de echo $PATH est la même que dans la version 1. env est la même.

Alors:

  • 1) Quel avantage y a-t-il à utiliser l' export rapport au paramètre PATH explicitement?
  • 2) Existe-t-il une différence fonctionnelle entre la version 1 et la version 2 lorsqu'elle est appliquée?
  • 3) Lequel dois-je utiliser et pourquoi?

Pour répondre spécifiquement à vos questions:

  1. export définit explicitement le $PATH .

  2. No. export définit l'environnement pour les process enfants, mais $PATH est déjà défini pour l'environnement actuel. Ainsi, dans le deuxième exemple, lorsque la command est lue – et avant l' export est exécutée – la valeur de l'environnement courant pour $PATH est étendue dans le mot $PATH .

  3. Vous devez utiliser ce qui est nécessaire et / ou confortable pour vous. Les deux ne font aucune différence sur le plan fonctionnel, donc c'est avant tout une question de style.

POSIX définit l' export embedded ainsi:

Le shell doit donner l'atsortingbut export aux variables correspondant aux noms spécifiés, ce qui les obligera à se find dans l'environnement des commands exécutées ultérieurement. Si le nom d'une variable est suivi de = word , la valeur de cette variable doit être définie sur word .

D'une autre de mes réponses :

Il y a peu de différence entre la déclaration d'une variable shell et d'une variable d'environnement. Parce que l'export est un construit, il déclare une variable d'environnement pour le process suivant invoqué, mais si vous n'invoquez pas celui qui rest le shell, votre variable est évaluée deux fois.

Vous pouvez supprimer toutes les exports sans aucun effet sur les variables exscopes tant que vous n'utilisez pas l' export pour évaluer deux fois. Par deux fois évaluer, je veux dire:

 var1=var2 export "${var1}=var3" echo "$var2" var3 

Au lieu de cela, utilisez simplement:

 set -a 

… en haut du script. Toutes les variables définies par la suite seront automatiquement exported – ce qui inclurait des variables que vous n'auriez pas export auparavant. Sinon, vous ne pouvez set -a pour une partie du script, puis set +a pour l'annuler. Cela peut également fonctionner comme une fonction.

Mais les sous-sets héritent automatiquement des valeurs de variables de toute façon, donc:

 var1=value ( echo "$(echo "$var1")" ) value 

export ne fait aucune différence dans ce cas.

Mais si votre script appelle un autre script ou tout autre exécutable qui interprète les valeurs que vous avez export et que vous cessez de les export , ces valeurs ne seront plus disponibles dans leur environnement. Dans l'exemple suivant, j'utilise la variable shell $PS1 – qui définit le contenu de l'invite d'un shell interactif – pour montrer comment les variations export variables ed export affectent les process enfants.

 export PS1="$(printf "this is another executable\n > ")" echo exit | sh -i ###OUTPUT### this is another executable > exit exit 

Mais …

 PS1="$(printf "this is another executable\n > ")" echo exit | sh -i ###OUTPUT### sh-4.3$ exit exit 

Mais encore une fois, si vous déclarez explicitement des variables d'environnement en invoquant un process …

 PS1="$(printf "this is another executable\n > ")" { echo exit | PS1=$PS1 sh -i echo exit | sh -i } ###OUTPUT### this is another executable > exit exit sh-4.3$ exit exit 

Tout file ENV abord appelé par un shell tel que .bashrc ou .profile définira des valeurs de variables pour la durée de vie de ce shell. Ainsi, toutes les variables définies et export dans ces files conserveront cette caractéristique d' export et seront export vers tous les process enfants invoqués par ce shell pour la durée de vie du shell ou jusqu'à ce qu'ils ne soient pas unset .

Il est notable cependant que bash étend quelque peu l' export à l'inclusion de l'option -n qui vous permet de supprimer l'atsortingbut d' export d'une variable sans l' unset , mais ce n'est pas un comportement portable.

Voici un fil similaire .

Une réponse courte:

https://superuser.com/a/153378/333431

Les variables exscopes sont transmises aux process fils, les variables non exscopes ne le sont pas.

Cela signifie que vous devez export vos variables si vous avez l'intention de les utiliser dans des sous-shell.

Vous pouvez tester ceci:

 $ TEST="im_not_here" $ echo $TEST im_not_here $ bash -c 'echo $TEST' <empty output> $ export TEST2="im_here" $ echo $TEST2 im_here $ bash -c 'echo $TEST2' im_here