web-dev-qa-db-fra.com

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

Quelle est la différence et laquelle est préférable d'utiliser lors de la personnalisation de mon profil bash? La documentation sur la commande export est rare, car il s'agit d'une cmd intégrée.

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

Sortie de echo $PATH est le même que dans la version 1. env est également le même.

Donc:

  • 1) Quel est l'avantage d'utiliser export par rapport à la définition explicite de PATH?
  • 2) Existe-t-il une différence fonctionnelle entre la version 1 et la version 2 lors de l'application?
  • 3) Lequel dois-je utiliser et pourquoi?
bashenvironment-variablespathprofile
22
njboot

Pour répondre spécifiquement à vos questions:

  1. export définit le $PATH explicitement.

  2. Non. export définit l'environnement des processus enfants, mais $PATH est déjà défini pour l'environnement actuel. Ainsi, dans le deuxième exemple, lorsque la commande est en lecture - et avant export est exécutée - la valeur de l'environnement actuel pour $PATH est développé dans le $PATH Word.

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

POSIX définit le export builtin donc:

Le shell doit attribuer l'attribut export aux variables correspondant aux noms spécifiés, ce qui doit les placer dans l'environnement des commandes 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'un autre de mes réponses :

Il y a peu de différence entre déclarer une variable Shell et une variable d'environnement. Étant donné que l'exportation est une fonction intégrée, elle déclare une variable d'environnement pour le processus suivant invoqué, mais si vous n'en invoquez pas un, ce processus reste le Shell, et donc votre variable est évaluée deux fois.

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

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

Utilisez plutôt:

set -a

... en haut du script. Toutes les variables définies par la suite seront automatiquement exported - ce qui inclurait des variables que vous ne pourriez pas avoir précédemment exported. Alternativement, vous ne pouvez que set -a pour une partie du script et plus tard set +a pour le désactiver - cela pourrait aussi fonctionner comme une fonction.

Mais les sous-coquilles héritent automatiquement des valeurs des 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 exported et que vous cessez de export, alors ces valeurs ne seront plus disponibles dans leur environnement. Dans l'exemple suivant, j'utilise la variable Shell $PS1 - qui définit le contenu d'une invite interactive du shell - pour montrer comment les variations des variables exported affectent les processus 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 là encore, si vous déclarez explicitement des variables d'environnement lors de l'appel d'un processus ...

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 fichier ENV appelé pour la première fois par un shell tel que .bashrc ou .profile définira des valeurs variables pour la durée de vie de ce shell. Ainsi, toutes les variables définies et exported dans ces fichiers conserveront cette caractéristique export et seront exported à tous les processus enfants invoqués par ce Shell pour la durée de vie du Shell ou jusqu'à ce sont unset.

Il est à noter, cependant, que bash étend quelque peu le export intégré pour inclure le -n option - qui vous permet de supprimer l'attribut export d'une variable sans unsetting, mais ce n'est pas un comportement portable.

13
mikeserv

Voici un fil similaire .

Une réponse courte:

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

Les variables exportées sont transmises aux processus enfants, pas les variables non exportées.

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

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
9
polym