Considérons un exemple spécifique. La grep
commande utilise une variable d'environnement appelée GREP_OPTIONS
pour définir les options par défaut.
Maintenant. Étant donné que le fichier test.txt
contient les lignes suivantes:
line one
line two
l'exécution de la commande grep one test.txt
retournera
line one
Si vous exécutez grep avec l’ -v
option, elle renverra les lignes qui ne correspondent pas, ainsi le résultat sera
line two
Nous allons maintenant essayer de définir l’option avec une variable environnementale.
Les variables d'environnement définies sans export
ne seront pas héritées de l'environnement des commandes que vous appelez.
GREP_OPTIONS='-v'
grep one test.txt
Le résultat:
line one
De toute évidence, l'option -v
n'a pas été transmise à grep
.
Vous souhaitez utiliser ce formulaire lorsque vous définissez une variable à utiliser uniquement par le shell, par exemple si for i in * ; do
vous ne souhaitez pas exporter $i
.
Cependant, la variable est transmise à l’environnement de cette ligne de commande, vous pouvez donc effectuer cette opération.
GREP_OPTIONS='-v' grep one test.txt
qui retournera le prévu
line two
Vous utilisez ce formulaire pour modifier temporairement l'environnement de cette instance particulière du programme lancé.
L'exportation d'une variable entraîne l'héritage de la variable:
export GREP_OPTIONS='-v'
grep one test.txt
revient maintenant
line two
C’est le moyen le plus courant de définir des variables pour l’utilisation de processus lancés ultérieurement dans un shell.
Tout a été fait à Bash. export
est un bash intégré; VAR=whatever
est la syntaxe bash. env
d'autre part, est un programme en soi. Quand env
est appelé, les choses suivantes se produisent:
- La commande
env
est exécutée comme un nouveau processus
env
modifie l'environnement, et
- appelle la commande fournie en argument. Le
env
processus est remplacé par le command
processus.
Exemple:
env GREP_OPTIONS='-v' grep one test.txt
Cette commande lancera deux nouveaux processus: (i) env et (ii) grep (en réalité, le deuxième processus remplacera le premier). Du point de vue du grep
processus, le résultat est identique à l’exécution
GREP_OPTIONS='-v' grep one test.txt
Cependant, vous pouvez utiliser cet idiome si vous êtes en dehors de bash ou si vous ne souhaitez pas lancer un autre shell (par exemple, lorsque vous utilisez la exec()
famille de fonctions plutôt que l' system()
appel).
Note complémentaire sur #!/usr/bin/env
C'est aussi pourquoi l'idiome #!/usr/bin/env interpreter
est utilisé plutôt que #!/usr/bin/interpreter
. env
ne nécessite pas un chemin d'accès complet à un programme, car il utilise la execvp()
fonction qui parcourt la PATH
variable, comme le fait un shell, puis se remplace par la commande exécutée. Ainsi, il peut être utilisé pour savoir où un interprète (comme perl ou python) "se repose" sur le chemin.
Cela signifie également qu'en modifiant le chemin actuel, vous pouvez influencer quelle variante python sera appelée. Cela rend possible ce qui suit:
echo -e '#!/usr/bin/bash\n\necho I am an evil interpreter!' > python
chmod a+x ./python
export PATH=.
calibre
au lieu de lancer Calibre, se traduira par
I am an evil interpreter!
export key=value
c'est une syntaxe étendue et ne doit pas être utilisé dans des scripts portables (c'est-à-dire#! /bin/sh
).