Récemment, j'ai remarqué que nous avons 3 options pour définir les variables d'environnement:
export envVar1=1setenv envVar2=2env envVAr3=3S'il existe d'autres moyens, veuillez nous éclairer.
Quand devrais-je préférer l'un à l'autre? Veuillez suggérer des directives.
Quant à la compatibilité shell, laquelle est la plus étendue (couvre plus de dialectes shell)?
J'ai déjà remarqué cette réponse, mais je souhaite développer la question avec envles directives de préférence d'utilisation.
Réponses:
export VARIABLE_NAME='some value'est la façon de définir une variable d'environnement dans toute enveloppe compatible POSIX ( sh, dash, bash, ksh, etc .; également ZSH). Si la variable a déjà une valeur, vous pouvez l'utiliser export VARIABLE_NAMEpour en faire une variable d'environnement sans modifier sa valeur.
Les shells Bourne pré-POSIX ne le supportaient pas, c'est pourquoi vous verrez des scripts à éviter export VARIABLE_NAME='some value'et à utiliser à la VARIABLE_NAME='some value'; export VARIABLE_NAMEplace. Mais les coques Bourne pré-POSIX sont extrêmement rares de nos jours.
setenv VARIABLE_NAME='some value'est la syntaxe csh pour définir une variable d'environnement. setenvn'existe pas dans sh, et csh est extrêmement rarement utilisé dans les scripts et a été dépassé par bash pour une utilisation interactive pendant les 20 dernières années (et zsh pendant encore plus longtemps), vous pouvez donc l'oublier à moins de le rencontrer.
La envcommande est très rarement utile sauf dans les lignes de shebang . Lorsqu'il est invoqué sans arguments, il affiche l'environnement, mais exportil le fait mieux (trié et souvent cité pour lever l'ambiguïté des nouvelles lignes dans les valeurs des nouvelles lignes qui séparent les valeurs). Lorsqu'elle est invoquée avec des arguments, elle exécute une commande avec des variables d'environnement supplémentaires, mais la même commande sans envfonctionne également ( VAR=value mycommands'exécute mycommandavec VARset to value, comme env VAR=value mycommand). La raison envest utile dans la ligne shebang, c'est qu'elle effectue une PATHrecherche et qu'il ne fait rien d'autre lorsqu'elle est invoquée avec un nom de commande. La envcommande peut être utile pour exécuter une commande avec seulement quelques variables d'environnement avec-i, ou sans paramètres pour afficher l'environnement, y compris les variables avec des noms non valides que le shell n'importe pas.
La définition d'une variable telle que l' VAR='asdf'environnement laisse inchangé, ce qui signifie que les programmes que vous lancez au cours de la même session ne sauront rien VARet ne pourront pas y accéder. Vous souhaitez ce comportement lors de l'écriture de scripts shell.
export, d'autre part, est une commande intégrée bash qui modifie l'environnement, rendant ainsi la variable exportée visible pour les processus enfants générés dans la session en cours. Vous pouvez obtenir le même résultat en exécutant VAR='asdf' %program_name%.
envn'est pas un programme intégré, mais un programme en soi. En surface, cela fonctionne exactement comme lorsque vous VAR='asdf' %program_name%, mais au niveau inférieur, les choses deviennent un peu plus compliquées. Tout d'abord, le envse lance. Il modifie l'environnement, puis exécute la commande avec les arguments donnés. Le même comportement que vous pouvez obtenir dans votre propre code en utilisant l' appel système exec (3) .
setenvest juste exportdans les coquilles de la famille csh, comme indiqué dans votre réponse.
Il y a plusieurs questions avec des réponses qui répondent à ceci:
Différence entre les variables shell exportées et celles qui ne sont pas en bash
Quelle est la différence d'utilisation entre les variables shell et les variables d'environnement?
(etc.)
VAR=asdfjour l'environnement s'ilVARétait déjà dans l'environnement. (Ce n'était pas vrai dans le shell Bourne d'origine.)