Dans la continuité de la précédente [Qu'est-ce qu'une entrée standard / une sortie standard?](/ Angel_p_57 / items / 03582181e9f7a69f8168), c'est une tentative d'expliquer des concepts et des bases qui peuvent être difficiles à comprendre pour les débutants de Linux / UNIX. Cette fois, nous parlons de ** variables d'environnement **. Windows a le même terme, et je pense que c'est conceptuellement similaire, mais il ne s'agit que de Linux / UNIX.
En ce qui concerne l'explication des variables d'environnement que vous voyez souvent, il existe de nombreuses discussions sur la façon de les utiliser, telles que "Ajouter à PATH pour exécuter des commandes dans ce répertoire" ou "Définir la langue avec LANG", mais dans cet article, Je ne parle pas vraiment de ça. Pour les variables d'environnement standard, par exemple, Chapitre Variables d'environnement standard POSIX peut être utile (en anglais). ).
En termes simples, une variable d'environnement est ** un type de paramètre permettant d'ajuster le comportement d'un programme **, qui est conservé et géré pour chaque processus **. Par conséquent, lorsqu'il s'agit de Linux / UNIX, la connaissance des variables d'environnement n'est requise que parce que ** il existe certaines situations où le comportement du programme est ajusté via des variables d'environnement **.
En passant, le terme "processus" mentionné ci-dessus est un terme qui fait référence à l'unité d'exécution [^ 1] d'un programme sur l'OS. Comme vous le savez peut-être, sous Linux / UNIX, le même programme peut être exécuté plusieurs fois et parfois en même temps, et le résultat obtenu de temps en temps varie en fonction de la situation [^ 2].
Les facteurs qui modifient le résultat sont l'entrée / sortie standard expliquée dans [Qu'est-ce qu'une entrée standard / une sortie standard?](/ Angel_p_57 / items / 03582181e9f7a69f8168), et divers fichiers de paramètres peuvent être impliqués en fonction du programme. Eh bien, il y a plusieurs choses. Cependant, seuls ** 2 types de paramètres sont spécifiés lors de l'exécution du programme en tant que système d'exploitation, à l'exclusion du nom de fichier du programme ** [^ 3]. L'un est le ** argument de ligne de commande ** et l'autre est la ** variable d'environnement **.
Juste au cas où, l'argument de ligne de commande est littéralement ** la chaîne de commande elle-même spécifiée pour exécuter le programme **, par exemple, si vous exécutez la commande ls -l, ls Les données du tableau [^ 4] sont décomposées en deux chaînes de caractères, ʻet -l`.
Puisque les arguments de ligne de commande et les variables d'environnement sont spécifiés lorsque le programme est exécuté, bien entendu ** non seulement les arguments de ligne de commande mais aussi les variables d'environnement sont gérés pour chaque processus **.
Peut-être que certaines personnes sont curieuses de connaître les programmes multithread. Les variables d'environnement sont communes au sein du processus, c'est-à-dire ** données partagées entre les threads **.
Et ces informations pour chaque processus peuvent être référencées via le système de fichiers proc dans le cas de Linux.
Par exemple, supposons que le même programme de veille exécute deux processus (PID 63, 64) comme suit:
État de la commande de veille
$ ps -fC sleep
UID PID PPID C STIME TTY TIME CMD
angel 63 5 0 17:51 pts/0 00:00:00 sleep 300
angel 64 5 0 17:51 pts/0 00:00:00 sleep 600
À ce stade, les arguments de ligne de commande de chaque processus et les ** variables d'environnement spécifiées à l'exécution sont lus en lisant les fichiers / proc / PID / cmdline et / proc / PID / environ [^ 5]. Tu peux savoir.
L'intérieur du fichier est séparé par des caractères NUL (code ASCII 0), il sera donc plus facile à lire si vous le changez en saut de ligne avec la commande tr. (Vous pouvez vérifier que le caractère NUL est utilisé avec la commande od.)
Exemple d'obtention d'informations à partir du système de fichiers proc
$ od -An -tc /proc/63/cmdline
s l e e p \0 3 0 0 \0
$ tr \\0 \\n < /proc/63/cmdline
sleep
300
$ tr \\0 \\n < /proc/64/cmdline
sleep
600
$ od -An -tc /proc/63/environ
P A T H = / b i n \0 H O G E = h
o g e \0
$ tr \\0 \\n < /proc/63/environ
PATH=/bin
HOGE=hoge
$ tr \\0 \\n < /proc/64/environ
PATH=/bin
UGE=uge
À partir de là, le programme de sommeil du PID 63 utilise deux éléments de sleep et 300 comme chaînes de caractères de ligne de commande et deux éléments de PATH = / bin et HOGE = hoge comme variables d'environnement, et de PID 64. Vous pouvez voir qu'il a été exécuté avec sleep, 600 et PATH = / bin, ʻUGE = uge`.
Jusqu'à présent, nous avons expliqué qu'il existe des arguments de ligne de commande et des variables d'environnement comme paramètres à spécifier lors de l'exécution d'un programme. Tous ces éléments servent à ajuster le comportement du programme. Mais pourquoi y a-t-il deux types? La raison n'est pas claire (car il s'agit d'un problème de conception en tant que système d'exploitation UNIX). Mais vous pouvez deviner. Nous aborderons en regardant la différence entre les deux.
Le premier est la différence de format de données. Un extrait d'un exemple de lecture des fichiers / proc / PID / cmdline et / proc / PID / environ est réimprimé.
Extrait d'un exemple d'obtention d'informations à partir du système de fichiers proc
$ tr \\0 \\n < /proc/63/cmdline
sleep
300
$ tr \\0 \\n < /proc/63/environ
PATH=/bin
HOGE=hoge
Vous pouvez voir que l'argument de ligne de commande est juste plusieurs chaînes, mais la variable d'environnement est une collection de paires «nom = valeur» [^ 7]. Comme vous pouvez l'imaginer, il existe les différences suivantes entre les deux.
Un «tableau associatif» est ce qu'on appelle un hachage ou un dictionnaire (dictionnaire) dans certains langages de programmation. En d'autres termes, s'il y a des données de «HOGE = hoge» dans la variable d'environnement, cela signifie que la valeur de «hoge» est associée à la clé de «HOGE».
Étonnamment, il n'y a pas de restrictions particulières sur les caractères, sauf que les caractères NUL (code ASCII 0) et = ne peuvent pas être utilisés comme clés. Cependant, il peut y avoir des problèmes lors de son fonctionnement réel [^ 8], il est donc plus sûr de le limiter aux caractères alphanumériques et aux traits de soulignement des caractères ASCII. (Il est d'usage d'utiliser des lettres majuscules)
À propos, l'état où il n'y a pas de clé spécifique dans la variable d'environnement et l'état où il y a une clé mais la valeur est vide (chaîne de caractères de longueur nulle) sont différents. (Certains programmes peuvent traiter différentes choses de la même manière) Voici un exemple d'exécution de la commande de date sans clé «TZ» indiquant le fuseau horaire et avec une clé mais une valeur vide. La différence est que le premier utilise le fuseau horaire par défaut du système et le second utilise UTC.
TZ(Informations sur le fuseau horaire)Différence de comportement de date due à
$ date #Pas de clé TZ, si la valeur par défaut du système est JST
Dimanche 2 décembre 2018 20:35:01 JST
$ TZ= date #Spécifiez un caractère vide pour la clé TZ et traitez-le comme UTC
Dimanche 2 décembre 2018 11:35:08 UTC
$ date -u #Spécifiez UTC dans l'argument de ligne de commande
Dimanche 2 décembre 2018 11:35:12 UTC
En passant, comme mentionné ci-dessus, une variable d'environnement est une collection de données multiples, mais il est difficile de dire quelque chose comme "la valeur associée à la clé de variable d'environnement" TZ "..." et personne ne le fait. Par conséquent, elle est généralement appelée "variable d'environnement" TZ "(valeur)" comme s'il y avait des données individuelles. «TZ» est aussi un «nom de variable d'environnement» plutôt qu'une «clé».
Vient ensuite la différence d'utilisation entre les deux.
Certains ont des effets comme la variable d'environnement TZ et l'argument de ligne de commande -u de date, et il n'est pas rare de combiner même des variables d'environnement et des arguments de ligne de commande qui ont exactement le même effet.
En d'autres termes, les deux ne sont pas utilisés correctement en fonction de ces "effets". La bonne utilisation des deux est plutôt pour des raisons administratives.
L'argument de ligne de commande est des données de tableau, tandis que la variable d'environnement est un tableau associatif. En d'autres termes, le premier a une structure gênante à trier même si des informations inutiles sont entrées, tandis que le second ignore simplement les clés inutilisées.
En d'autres termes, l'argument de ligne de commande ** est une utilisation qui spécifie uniquement les informations réellement nécessaires **, tandis que la variable d'environnement est la redondance qui ** fusionne les informations spécifiées dans divers programmes et les spécifie comme engagement maximum **. Il peut être utilisé avec le sexe.
Revenez maintenant à la variable d'environnement TZ.
J'ai donné un exemple avec la commande date plus tôt, mais en fait, il est également efficace pour divers programmes impliquant des informations temporelles telles que les fichiers liés à l'horodatage de ls et stat.
Effet de la variable d'environnement TZ sur ls
$ ls -l test.txt #Norme du système(Dans ce cas, JST)Sortie d'horodatage dans
-rwx------1 ange ange 398 2 décembre 20:52 test.txt
$ TZ= ls -l test.txt #Sortie d'horodatage en UTC
-rwx------1 ange ange 398 2 décembre 11:52 test.txt
Cela est dû au fait que la fonction de bibliothèque «localtime», qui calcule la date / heure / jour / seconde à partir de l'horodatage (heure UNIX [^ 9]), change son comportement en fonction de la variable d'environnement «TZ». Pour le dire autrement, les programmes tels que «ls» ne connaissent pas cette variable d'environnement.
Pensons-y ici. Lors de l'écriture d'un programme, il est rare de créer toutes ses fonctions à partir de zéro, et la plupart des traitements doivent utiliser une sorte de bibliothèque. Que faire si vous essayez d'ajuster toutes ces bibliothèques qui sont triviales pour le but principal du programme, mais qui peuvent être ajustées ** avec des arguments de ligne de commande **? L'interprétation des arguments de la ligne de commande peut être terriblement fastidieuse, et même de petites modifications apportées à la bibliothèque peuvent être accablantes.
Par conséquent, il est logique de séparer ** les parties liées aux fonctions individuelles du programme avec des arguments de ligne de commande et les fonctions communes telles que les bibliothèques avec des variables d'environnement **.
Dans certains cas, même s'il ne s'agit pas d'une bibliothèque, des variables d'environnement communes sont utilisées pour contrôler des fonctions similaires de plusieurs programmes. La variable d'environnement «LANG» [^ 10] qui contrôle la langue à utiliser, l'anglais ou le japonais, etc. est un exemple typique.
Donc, j'ai expliqué que les variables d'environnement peuvent être utilisées comme suit.
En outre, dans les bibliothèques standard et divers langages de programmation, les API qui contrôlent l'exécution du programme sont souvent conçues pour hériter des variables d'environnement du processus en cours vers le programme qui les démarre. [^ 11]
En raison des propriétés ci-dessus, par exemple, une fois que la variable d'environnement LANG est spécifiée comme ja_JP.UTF-8 (UTF-8 japonais), tous les processus ont démarré à partir de celle-ci (en héritant de la variable d'environnement) (programme). Modifiez le comportement de la sortie en japonais (tant qu'il est pris en charge)
Par conséquent, étant donné que divers programmes se comportent comme s'ils partageaient les mêmes paramètres, ils sont utilisés ** comme s'il s'agissait d'informations de réglage global qui contrôlent l'environnement d'exécution de divers programmes.
Mais il faut être prudent ici. Les variables d'environnement sont simplement transmises des informations du processus de démarrage par le comportement de "prise en charge par défaut". ** Le système d'exploitation ne disperse pas les paramètres communs avec une puissance mystérieuse **, donc lorsque vous vous connectez avec ssh, par exemple, lorsqu'un travail est exécuté avec cron, par exemple, une application côté serveur est exécutée à partir d'un serveur Web. À ce moment-là, le contenu des variables d'environnement peut être complètement différent selon le processus de démarrage.
Par conséquent, en ce qui concerne les variables d'environnement, il est préférable de savoir comment et à partir de quel programme l'information est héritée et l'étendue de son influence.
Jusqu'à présent, nous n'avons parlé de passer des variables d'environnement que lors de l'exécution d'un programme, mais même après le démarrage du programme **, vous pouvez faire fonctionner vous-même les variables d'environnement (ajouter, supprimer des clés, changer la valeur correspondant à la clé) * *.
Dans ce qui suit, nous examinerons le fonctionnement des variables d'environnement dans chaque situation.
Lorsque le programme démarre, il reçoit des variables d'environnement du système d'exploitation, mais l'API de langage C dédiée gère les opérations suivantes. OS n'est pas impliqué.
/ proc / PID / environ.L'API typique est la suivante.
Notez que ** la modification des variables d'environnement n'est pas thread-safe **. Dans un programme multi-thread, la variable d'environnement elle-même est des données partagées entre les threads, donc si vous ne tenez pas compte de la cohérence entre les threads lors des modifications, cela peut provoquer des dysfonctionnements et utiliser différentes variables d'environnement dans différents threads. Vous ne pouvez pas.
Puisque le rôle principal du shell est de contrôler l'exécution du programme, je pense que la manipulation des variables d'environnement dans le shell est la méthode la plus courante.
Et dans le cas du shell, ** les variables d'environnement peuvent être gérées en étendant les variables du shell **.
Plus précisément, dans le cas de bash, vous pouvez faire référence à / modifier des variables normales et faire référence à / modifier des variables d'environnement exactement de la même manière [^ 12]. Une différence est "d'ajouter ou non l'attribut d'être une variable d'environnement".
Vous pouvez voir si une variable est une variable régulière ou une variable d'environnement avec la commande declare. Cette commande declare peut également être utilisée pour ajouter des attributs de variable d'environnement. (Bien que la commande la plus courante soit la commande ʻexport`)
Exemple de fonctionnement variable
$ declare -p SHELL #SHELL est généralement une variable d'environnement( -Vu par x)
declare -x SHELL="bash"
$ echo $SHELL # $Peut être référencé par le nom de la variable
bash
$ HOGE=hoge #Si vous définissez simplement une variable, la valeur par défaut est une variable normale
$ declare -p HOGE # -Puisqu'il n'y a pas de x, il peut être compris comme une variable normale
declare -- HOGE="hoge"
$ echo $HOGE # $Peut être référencé par le nom de la variable
hoge
$ declare -x HOGE #Octroi d'attributs de variable d'environnement(Si vous souhaitez supprimer l'attribut+Faire avec x)
$ declare -p HOGE #Vous pouvez voir qu'il est devenu une variable d'environnement
declare -x HOGE="hoge"
$ HOGE=hogehoge #Une fois l'attribut de variable d'environnement attaché, l'attribut reste le même même si la valeur est modifiée.
$ declare -p HOGE #Variables d'environnement fixe
declare -x HOGE="hogehoge"
$ UGE=uge; export UGE #l'exportation fait également des attributs de variable d'environnement(La définition peut être faite avec une seule commande)
$ declare -p UGE #Vous pouvez voir que c'est une variable d'environnement
declare -x UGE="uge"
$ unset UGE #Supprimer les variables régulières et les variables d'environnement
$ declare -p UGE #Ce sera une erreur car il a été supprimé
bash: declare: UGE:Pas trouvé
Les variables d'environnement définies de cette manière affectent le comportement du shell lui-même, ainsi que les commandes exécutées depuis le shell en général.
Pour voir toutes les informations sur les variables d'environnement, exécutez la commande declare -x sans spécifier le nom de la variable. Vous pouvez également exécuter la commande printenv.
Cependant, vous pouvez définir temporairement la variable d'environnement lors de l'exécution de la commande, ou vous pouvez exécuter la commande avec la variable d'environnement supprimée (afin qu'elle ne puisse pas être héritée).
Changement de variable temporaire
$ declare -p LANG TZ #LANG est japonais UTF, TZ est aucun(Fuseau horaire par défaut)
declare -x LANG="ja_JP.UTF-8"
bash: declare: TZ:Pas trouvé
$ date -d 2018-12-25T00:00+0900
Mardi 25 décembre 2018 00:00:00 JST
$ LANG= TZ=America/Los_Angeles date -d 2018-12-25T00:00+0900 #Temporairement LANG,Définir TZ
Mon Dec 24 07:00:00 PST 2018
$ declare -p LANG TZ #Les variables d'environnement du shell lui-même n'ont pas changé
declare -x LANG="ja_JP.UTF-8"
bash: declare: TZ:Pas trouvé
$ ( exec -c date -d 2018-12-25T00:00+0900 ) #Exécuté avec les variables d'environnement effacées, ne s'affiche plus en japonais
Tue Dec 25 00:00:00 JST 2018
$
Dans l'exemple ci-dessus, la commande ʻexec est exécutée dans un sous-shell avec la commande ʻexec entre parenthèses car la commande ʻexec a pour effet de ** exécuter le programme sous la forme d'un remplacement du shell actuel **. .. Les parenthèses ne sont pas obligatoires si le shell n'a plus besoin de continuer à fonctionner. ~~ Alternativement, si vous exécutez simplement ʻexec -c sans un nom de commande entre parenthèses, les variables d'environnement du shell en cours d'exécution seront effacées. ~~ * Je suis désolé, cette description semble avoir été mal comprise, je vais donc l'annuler.
Cependant, dans le cas de bash, la définition temporaire des variables d'environnement et la compensation temporaire ne peuvent pas être utilisées ensemble. Si vous voulez l'utiliser ensemble, vous pouvez utiliser la commande ʻenv`.
exemple de commande env
$ date -d 2018-12-25T00:00+0900 #État brut
Dimanche 2 décembre 2018 20:41:02 JST
$ env TZ=America/Los_Angeles date #Réglage TZ uniquement
Dimanche 2 décembre 2018 03:41:12 PST
$ env - /bin/date #Effacer les variables d'environnement et exécuter
Sun Dec 2 20:41:30 JST 2018
$ env - PATH=/bin:/usr/bin TZ=America/Los_Angeles date #Définir TZ après avoir effacé les variables d'environnement
Sun Dec 2 03:41:44 PST 2018
De cette manière, vous pouvez simplement définir temporairement les variables d'environnement, les effacer ou utiliser les deux.
Cependant, si vous effacez la variable d'environnement, la variable d'environnement PATH sera également effacée, de sorte que le fichier programme ne sera pas recherché automatiquement à partir du nom de la commande. Par conséquent, il est nécessaire de spécifier le nom du fichier tel que / bin / date ou de redéfinir la variable d'environnement PATH.
Comme autre exemple, je présenterai make, qui traite étroitement les variables gérées dans l'outil et les variables d'environnement.
make est un outil traditionnellement utilisé pour construire des programmes (compiler et lier des programmes qui sont divisés en plusieurs fichiers, les installer dans le répertoire système).
Voici un exemple de création d'un fichier Makefile qui contrôle le comportement de make et de sortie du contenu des variables et des variables d'environnement via celui-ci. Je ne peux pas me permettre d'expliquer comment l'utiliser, mais j'espère que vous pouvez voir comment il est géré de manière similaire.
Exemple d'utilisation de variables par make lui-même
$ cat > Makefile #Créez d'abord Makefile, Ctrl-Terminer l'entrée avec D
HOGE ?= hoge #Paramètres variables(Seulement lorsqu'il n'est pas défini)、$(Nom de variable)Voir dans
default:
#Sortir le contenu de la variable
@echo $(HOGE)
#Variables d'environnement de sortie(Si défini)
@printenv HOGE
^D
$ make #Printenv échoue car les variables de make ne sont pas des variables d'environnement
hoge
Makefile:4:cible'default'Échec de la recette
make: *** [default]Erreur 1
$ HOGE=hogehoge make #Même s'il est défini comme une variable d'environnement, il est traité comme une variable
hogehoge
hogehoge
$ make HOGE=hogehoge #Défini comme variable d'environnement lorsqu'il est spécifié comme argument de ligne de commande
hogehoge
hogehoge
Ensuite, je vais aborder la manière de manipuler les variables d'environnement dans divers langages de script (Perl, Python, Ruby).
Dans ces langages, vous pouvez manipuler des variables d'environnement comme si vous manipuliez des tableaux associatifs (dictionnaires / hachages).
Pour Perl, c'est % ENV, pour Python, le module os ʻos.environ, et pour Ruby, ʻENV.
Ce ne sont pas seulement des variables, ce sont des données spéciales qui exécutent des API en langage C telles que getenv et putenv via des opérations.
Voici les scripts qui définissent la variable d'environnement TZ et la reflètent dans l'affichage de l'heure actuelle.
date.pl
use POSIX;
print strftime("%c",localtime),"\n";
$ENV{TZ}="America/Los_Angeles";
print strftime("%c",localtime),"\n";
date.py
import datetime
import os
print(datetime.datetime.now().strftime("%c"))
os.environ["TZ"]="America/Los_Angeles"
print(datetime.datetime.now().strftime("%c"))
date.rb
puts Time.now.strftime("%c")
ENV["TZ"]="America/Los_Angeles"
puts Time.now.strftime("%c")
Ils spécifient le même format de sortie avec la même API strftime. Vous pouvez voir qu'il y a un décalage pour le fuseau horaire avant et après la modification des variables d'environnement.
Exécution de chaque script
$ unset LANG
$ perl date.pl
Sun Dec 2 18:47:35 2018
Sun Dec 2 01:47:35 2018
$ python3 date.py
Sun Dec 2 18:47:40 2018
Sun Dec 2 01:47:40 2018
$ ruby date.rb
Sun Dec 2 18:47:44 2018
Sun Dec 2 01:47:44 2018
Il y a une mise en garde lors de la manipulation des variables d'environnement pendant l'exécution du programme.
Autrement dit, ** la modification d'une variable d'environnement n'a pas toujours un effet immédiat **. Cela est dû au fait que certaines bibliothèques examinent les variables d'environnement uniquement lorsque le programme est démarré et exécutent le traitement d'initialisation, et après cela, les modifications des variables d'environnement peuvent ne pas être suivies.
En fait, la variable d'environnement LANG qui ajuste la langue a aussi un tel aspect.
Comme dans l'exemple Perl suivant, après avoir changé la variable d'environnement, si vous n'appelez pas explicitement POSIX :: setlocale, la` modification ne sera pas reflétée [^ 13].
Réflexion de LANG en Perl
$ #Si LANG est défini depuis le début, il sera émis en japonais
$ LANG=ja_JP.UTF-8 perl -CO -MPOSIX -E 'say strftime("%c",localtime)'
2 décembre 2018 19:55:54
$ #Changer simplement LANG après le démarrage ne le rend pas japonais
$ LANG=C perl -CO -MPOSIX -E '$ENV{LANG}="ja_JP.UTF-8"; say strftime("%c",localtime)'
Tue Dec 2 19:56:21 2018
$ #Les changements de LANG sont reflétés par setlocale
$ LANG=C perl -CO -MPOSIX -E '$ENV{LANG}="ja_JP.UTF-8"; setlocale(LC_ALL,""); say strftime("%c",localtime)'
2 décembre 2018 19:56:34
S'il s'agit d'une variable d'environnement devant être héritée par un autre programme à exécuter, vous n'avez pas besoin d'en être très conscient, mais si vous voulez changer le comportement de votre propre processus, soyez prudent lorsque le changement de cette variable d'environnement est reflété dans la bibliothèque. Je pense que c'est bien.
C'est donc un résumé.
[^ 1]: ** Process **: Vous pouvez lister par ps ou par commande top, mais ils se distinguent par un ID appelé PID. C'est tout.
[^ 2]: ** Cela dépend de la situation **: Certaines commandes, comme la commande / bin / true, donnent toujours le même résultat sauf s'il y a une erreur systématique, mais de telles commandes ne sont pas utiles.
[^ 3]: ** Paramètres à spécifier lors de l'exécution du programme **: Pour plus de détails, voir page de manuel exeve (2) .html). execve est une API OS (appel système) qui exécute des programmes.
[^ 4]: ** Données de séquence décomposées **: Bien sûr, dans le shell, l'utilisateur entre la commande sous la forme d'une chaîne de caractères, mais elle est décomposée et transmise au système d'exploitation sous forme d'informations de séquence. est.
[^ 5]: ** Lire le fichier **: L'argument de ligne de commande / proc / PID / cmdline peut être lu par n'importe qui, mais la variable d'environnement / proc / PID / environ est l'exécuteur du processus ou Il ne peut être lu que par root.
[^ 6]: ** Non reflété **: Pour dire la vérité, il n'y a aucun moyen de changer le contenu plus tard, mais je vais l'omettre.
[^ 7]: ** Nom = paire valeur **: Il est possible de transmettre des données dans un format qui n'est pas nom = valeur (le système d'exploitation transmet simplement les données spécifiées). Cependant, on ne sait pas quel effet cela aura et peut-être aucune garantie ne peut être obtenue.
[^ 8]: ** Problèmes potentiels **: En termes simples, ces variables d'environnement ne peuvent plus être manipulées dans le shell.
[^ 9]: ** Heure UNIX **: L'heure UNIX est la durée gérée par le nombre de secondes écoulées depuis 1970/1/1 00:00 appelé Epoch.
[^ 10]: ** Variable d'environnement LANG **: Cela dit, la variable d'environnement LANG est importante en ce qu'elle affecte le réglage de la langue par la fonction de bibliothèque setlocale, donc cela peut être plus pour la bibliothèque. Pas du tout.
[^ 11]: ** Bibliothèque standard pour l'exécution **: La famille dite exec de fonctions de bibliothèque est applicable. Pour plus de détails, reportez-vous à la page de manuel exec (3). Bien sûr, il existe des API (ʻexecle, ʻexecvpe) qui peuvent spécifier des variables d'environnement, mais d'autres API montrent le comportement d'hériter des variables d'environnement.
[^ 12]: ** Extension des variables normales **: Dans le cas de csh / tcsh, l'interface de paramétrage / modification est séparée (commandes setenv, ʻunsetenvpour les variables d'environnement). Cependant, il est similaire à bash que vous pouvez vous référer au contenu avec$ variable name. [^ 13]: ** Non reflété sauf si setlocale est appelé **: Inversement, on peut dire que la langue est automatiquement définie en appelant setlocaleuniquement lorsque le programme est lancé. Cependant, si le traitement n'est pas lié à «setlocale» alors que la variable d'environnement «LANG» est affectée, elle peut être affectée immédiatement. Si vous ne pensez pas à hériter des variables d'environnement vers d'autres programmes, il est plus rapide de spécifier la langue directement avecsetlocale sans réinitialiser les variables d'environnement LANG`.
Recommended Posts