6 votes

Quelle est la portée de "exporté" dans les variables Unix Shell ?

J'ai défini certaines variables d'environnement de la manière suivante :

MY_VAR='helloworld'
export MY_VAR

Ensuite, je suis passé à un autre utilisateur via

su SOME_OTHER_USER

Je fais écho à la variable MY_VAR et je vois sa valeur !

1) Pouvez-vous expliquer ce problème ? D'après ce que je comprends, lorsque j'exporte une variable via la commande export, il ne s'agit pas d'une exportation "globale", mais d'une variable locale à l'utilisateur. Pourquoi est-ce que je vois cela ?

2) Initialement, j'avais une supposition : peut-être, quand je passe à un autre utilisateur, je démarre un processus enfant de mon processus bash, et c'est pourquoi je peux voir ma variable parce que les vars exportées sont passées à tout processus enfant de Shell actuel. Mais la commande ps ---pid <my bash's pid which I got with echo $$> ne montre que le même pid en sortie. Il semble donc que cela signifie qu'il n'y a pas de processus enfant lié à mon processus bash et que su ne démarre aucun processus. Est-ce que j'ai raison ? (au fait, je ne vois pas un seul 'enfant' de cette façon, même si je démarre un autre processus bash avec la commande bash, je ne sais pas pourquoi).

3) Enfin, qui peut voir la variable que j'ai exportée de cette façon ? Si je lance un autre processus à partir de l'interface graphique de mon système d'exploitation, vais-je la voir ? Il semble que non, car si je lance un autre terminal, je ne la vois pas. Quelle est donc la portée et la durée de vie de ma variable exportée ?

J'utilise Debian Wheezy. J'exécutais ma commande depuis RootTerminal sous l'utilisateur Root.

4voto

Scott Points 20468
  • OK, pour commencer, je pense que tu veux dire ps --pid et non ps ---pid .

  • Vous n'avez pas besoin de echo $$ puis tapez le numéro dans ps --pid _number_ ; il suffit de taper ps --pid $$ .  A moins que vous ne parliez de

    # echo $$
    42
    # su joe
    % ps --pid 42

    dans ce cas, vous faites la bonne chose.

  • A quoi vous attendiez-vous ?

    --pid pidlist

    Sélectionnez par l'ID du processus.  Identique à -p y p .

    -p pidlist

    Sélection par PID.  Ceci sélectionne les processus dont les numéros d'identification de processus apparaissent dans pidlist .  Identique à p y --pid .

    Donc, quand vous faites ps --pid _PID_of_shell_ , vous obtenez la ligne de ps La sortie de l'entreprise pour le processus Shell uniquement .  Vous pourriez trouver ps -l | grep _PID_of_shell_ plus utile ; il affichera toute ligne qui contient _PID_of_shell_ n'importe où, y compris dans la colonne PPID.  C'est-à-dire qu'il montrera les processus enfants du Shell.  Mais, bien sûr, grep 42 vous trouverez des choses comme 7428 .

  • Vous avez raison ; les variables d'environnement sont transmises du parent à l'enfant.  Comme indiqué ci-dessus, votre su Shell est un enfant de votre login Shell. (ou un autre parent Shell).  Notez cependant qu'un processus peut modifier son environnement ; sudo est un peu connu pour faire ça, et  su le fait également (par exemple, il modifie $USER , $LOGNAME y $HOME à moins que vous ne spécifiez --preserve-environment , et encore plus si vous spécifiez --login ).  De plus, un processus peut passer à ses enfants un environnement différent que celui qu'il utilise ; le Shell le fait lorsque vous dites quelque chose comme PAGER=cat man _man_page_topic_ .  Références : 1 , 2 .

  • Donc, non, si vous définissez (exportez) une variable d'environnement dans le Shell. dans un terminal, et qu'ensuite vous démarrez un autre terminal via le gestionnaire de fenêtres, il ne verra pas la variable d'environnement, parce qu'il n'est pas un enfant (ou descendant) de la Shell qui l'a définie.  Mais, si vous démarrez une nouvelle fenêtre de terminal à partir du Shell (par exemple, par xterm& ), alors cette fenêtre de terminal héritera de l'environnement du Shell.

0voto

Daniel Liston Points 336

Il serait peut-être plus facile de comprendre si vous accédiez à la machine avec ssh, rlogin ou telnet, même en tant que même utilisateur. (rlogin/telent ne sont pas recommandés)

Si vous définissez et exportez une variable à partir de tty1 en tant qu'utilisateur foo, tout processus enfant peut voir la variable et sa valeur. Mais si vous démarrez une toute nouvelle session, c'est-à-dire à partir de tty2, en tant qu'utilisateur foo, la variable ne sera pas visible.

1) Lorsque vous exportez une variable, vous la rendez globale (dans le contexte de la session). Comme une note latérale, je déconseille fortement l'utilisation de travailler dans un Shell "root". Les erreurs et les accidents sont beaucoup moins pardonnés lorsqu'ils sont exécutés par cet utilisateur/compte.

2) La commande su est un utilitaire permettant de définir (ou de changer) l'utilisateur. Vous êtes toujours dans votre session d'origine. C'est pourquoi vous pouvez toujours voir votre variable exportée.

3) La portée est la session actuelle et la durée de vie est la durée de cette session (jusqu'à ce que vous vous déconnectiez, en supposant que vous ne réinitialisiez pas ou ne modifiiez pas à nouveau la variable). Si vous créez de nouveaux xterms à partir de la session parent, les enfants voient toujours votre variable exportée. Si vous démarrez de nouvelles sessions/terminaux, les variables et leurs valeurs provenant des autres terminaux ne sont pas visibles.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X