Perl a accès à certaines variables d'environnement:
> echo $env
opsd
> perl -E 'say $ENV{env}'
(no response from Perl)
> perl -E 'say `echo \$env`'
(no response from Perl)
Mais apparemment, il existe une autre classe de variables d'environnement qui ne sont pas dans le hachage ENV:
> echo $HOST
xtt006
> perl -E 'say $ENV{HOST}'
xtt006
> perl -E 'say `echo \$HOST`'
xtt006
3 Réponses :
Essayez d ' exporter votre variable depuis le shell. Cela le déplacera de la liste des variables du shell vers l'environnement que tous les sous-processus pourront voir.
export env
perl -E 'say $ENV{env}'
Cela devrait le faire apparaître.
Dans bash, printenv listera toutes les variables d'environnement exportées (qui seraient héritées par un processus enfant), et set listera toutes les variables, y compris les variables d'environnement locales dans votre shell.
Nous utilisons csh ici, et j'ai "export: Command not found". / bin / env montre la plupart (mais pas la totalité) de mes variables d'environnement. "echo $ env" renvoie opsd, tandis que "env | grep env" ne renvoie rien.
Depuis % ENV en perlvar (je souligne)
Le hachage
% ENVcontient votre environnement actuel.
L ' environnement est hérité du processus qui a lancé le processus Perl, ici le shell.
Cependant, les variables shell peuvent être locales , qui ne sont pas transmises aux processus enfants, ou globaux, qui forment l'environnement et sont hérités par les processus enfants. Les fichiers globaux sont principalement lus à partir des fichiers de configuration au démarrage, mais s'ils doivent être ajoutés plus tard, ils doivent être exporté
Une variable créée comme celles de l'exemple ci-dessus n'est disponible que pour le shell actuel. C'est une variable locale: les processus enfants du shell actuel ne connaîtront pas cette variable. Afin de passer des variables à un sous-shell, nous devons les exporter à l'aide de la commande intégrée
export. Les variables exportées sont appelées variables d'environnement . La configuration et l'exportation se font généralement en une seule étape:setenv env "value"
(je souligne) D'après votre description, il semble que $ env soit ajouté en tant que variable locale (avec set ), qui doit également être exportée ( export env ) afin d'être vu dans le one-liner.
Les variables d'environnement peuvent être listées avec env ou printenv code>, tandis que set répertorie toutes les variables, locales et d'environnement.
Ce qui précède se réfère au shell bash . La notion d '«environnement» est la même dans d'autres coquilles, et le même raisonnement s'applique là aussi; pour qu'une variable soit vue dans les processus enfants, nous devons la rendre globale ("variable d'environnement"). La différence réside dans la manière de procéder.
Dans csh / tcsh , utilisez
export VARNAME="value"
au lieu de set var = " value ", ce qui créerait une variable locale.
En plus d'utiliser une variable globale (" environnement ") au lieu d'une variable locale, on peut passer la variable au code Perl. Voir ce post et ce post pour des exemples de faire cela avec des one-liners. Si un script réel est appelé, faites-lui prendre des arguments; le moyen standard, et le plus agréable, est avec Getopt :: Long ,
Ce n'est pas une exigence particulière pour les utilisateurs; ils utilisent votre script et doivent l'invoquer correctement.
@ user3358338 Mis à jour par rapport à un shell autre que bash
Existe-t-il un csh équivalent à «exporter»? Même si c'est le cas, ce n'est pas une très bonne solution ... Je ne voudrais pas que les utilisateurs de mon script Perl doivent "exporter env" avant d'exécuter le script.
@ user3358338 Non (pas à ma connaissance) - dans csh / tcsh c'est soit set soit setenv . Quant à ce que les utilisateurs feraient ... s'ils s'attendent à ce que votre script connaisse une variable, ils doivent soit la rendre globale, soit la transmettre au script. Pouvez-vous expliquer un peu plus?
Je ne suis pas la personne qui a donné à $ env la valeur d'opsd. Je viens de me connecter et le trouve dans cet état. Je ne doute pas que cela ait été fait avec set env = "opsd" , comme vous le dites. J'aimerais que mon script Perl puisse utiliser cette valeur. Je trouve étrange que csh ait accès à cette valeur (avec echo $ env ), mais il n'y a aucun moyen que Perl, lancé depuis le csh qui a accès à cette valeur, puisse avoir accès à cette valeur.
@ user3358338 Ouais, compris. Mais set env = ... crée une variable locale qui n'est tout simplement pas vue par les processus dérivés de ce script. C'est comme ça. On peut: (1) le rendre global à la place (2) Appeler le script et lui passer la valeur. Cela, je pense, est parfaitement logique. Ils appellent votre script et ils l'invoquent comme il convient.
@ user3358338 Ajout d'un commentaire et de quelques liens pertinents à la fin.
Tout comme Perl a des variables privées ( my $ x ) et des variables d'environnement ( $ ENV {Y} ), le shell aussi.
setenv VAR val
perl -e'...$ENV{VAR}...'
Non, je ne le vois pas quand je lance "env". Mais je le vois avec "echo $ env".
Oui je devrais. On m'a dit "vous affichez la valeur de la variable d'environnement 'foo' en tapant 'echo $ foo', et apparemment c'était une explication trop simpliste. Env est-il une" variable shell locale ", comme zdim l'indique ci-dessous?
" trop simpliste ... " --- en effet,
echo $ fooaffiche la valeur de toute variable shell, locale ou d'environnement. Maisenv(ouprintenv) n'affiche que les variables d'environnement (toutes).