Discussion :

[liloulinx]

Bonjour.
J'utilise plusieurs scripts Shell et Perl sur plusieurs machines.
Pour rendre les scripts compatibles entre eux (les mêmes sur toutes les machines), j'ai décidé de créer des variables d'environnement que j'ai déclarées et exportées dans "/etc/bash.bashrc". Mes scripts sont maintenant normalisés et donc les mêmes sur toutes mes machines. C'est les var d'env qui diffèrent d'une machine à une autre.
Les scripts Shell fonctionnent sans problème, par contre les scripts Perl n'arrivent pas à lire ces var d'env. Ils lisent celles du fichier bashrc déclaré dans le répertoire de l'utilisateur (Ex. pour root c'est le fichier : /root/.bashrc).
Pouvez-vous me dire SVP comment faire pour dire à Perl d'utiliser le fichier "/etc/bash.bashrc" au lieu de /root/.bashrc ?
En vous remerciant.
AL

[Lolo78]

Bonjour,

Tu ne donnes pas assez de détails.

Est-ce que, dans ton script /etc/bash.bashrc, tu exportes tes variables d'environnement?

Est-ce que ton script Perl est lancé par un shell?

Dans les deux cas, si tu exportes les variables d'environnement dont tu as besoin, alors ton programme Perl devrait y accéder sans problème.

Sinon, fais l'export dans le shell.

Sinon, dernière solution, il faut lire explicitement /etc/bash.bashrc dans le programme Perl et récupérer les variables voulues.

[dmganges]

Bonjour,
Je ne comprends certainement pas ton problème, c'est pour faire avancer le Schmilblick

/etc/bash.bashrc s’exécutant avant le .bashrc de l'utilisateur, tu devrais retrouver tes variables,
Sauf dans le cas d'exécution à distance, par connexion telnet, ssh... auquel cas il faudrait invoquer /etc/bash.bashrc dans ton script Perl...
C'est le pb récurrent : un script à distance ne fait pas une connexion, DONC les variables d'environnement ne sont pas générées...
Dans ce cas, perso je préfèrerai placer les nouvelles variables dans un fichier exécutable (ENV par exemple), l'invoquer dans les /etc/bash.bashrc ET et invoquer seulement le fichier (ENV) dans les script Perl...
Donc pour ce point on verra plus tard si tu es dans cette situation...

Dans un environnement Cygwin,
je crée une variable VARPERSO dans etc/bash.bashrc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
...
# Set a default prompt of: user@host and current_directory
PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
 
# Uncomment to use the terminal colours set in DIR_COLORS
# eval "$(dircolors -b /etc/DIR_COLORS)"
 
# AJOUT :
export VARPERSO="Michel"

J'ouvre un autre terminal, donc /etc/bash.bashrc et .bashrc sont exécutés, et j'ai bien la variable VARPERSO

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Michel@MiDo ~
$ perl -e 'print $ENV{VARPERSO};'
Michel
Michel@MiDo ~

PS : en ce moment je n'ai pas d'environnement Unix/Linux à disposition, je fais dans Cygwin, je ne pourrais pas faire tous les tests nécessaires...

[EDIT 20:07] Grillé par Lolo78

[liloulinx]

Bonjour,

Tu ne donnes pas assez de détails.

Est-ce que, dans ton script /etc/bash.bashrc, tu exportes tes variables d'environnement?

Oui, je les ai exportées. Les scripts Shell que j'utilise arrivent à lire le contenu de ces variables mais pas perl. J'ai constaté que Perl lit les var que j'ai déclarées (pour test) dans le fichier bashrc de l'utilisateur (ex. /root/.bashrc) et non pas celles déclarées dans le fichier bashrc global (/etc/bash.bashrc).

Est-ce que ton script Perl est lancé par un shell?

Le scipt Perl est lancé par la commande "Perl" dans la crontab de l'utilisateur root.

Dans les deux cas, si tu exportes les variables d'environnement dont tu as besoin, alors ton programme Perl devrait y accéder sans problème.
Sinon, fais l'export dans le shell.
Sinon, dernière solution, il faut lire explicitement /etc/bash.bashrc dans le programme Perl et récupérer les variables voulues.

C'est ce que je veux faire mais je ne sais pas comment le faire. Je ne connais pas trop Perl.

[liloulinx]

Bonjour,
Je ne comprends certainement pas ton problème, c'est pour faire avancer le Schmilblick

/etc/bash.bashrc s’exécutant avant le .bashrc de l'utilisateur, tu devrais retrouver tes variables,
Sauf dans le cas d'exécution à distance, par connexion telnet, ssh... auquel cas il faudrait invoquer /etc/bash.bashrc dans ton script Perl...
C'est le pb récurrent : un script à distance ne fait pas une connexion, DONC les variables d'environnement ne sont pas générées...
Dans ce cas, perso je préfèrerai placer les nouvelles variables dans un fichier exécutable (ENV par exemple), l'invoquer dans les /etc/bash.bashrc ET et invoquer seulement le fichier (ENV) dans les script Perl...
Donc pour ce point on verra plus tard si tu es dans cette situation...

C'est la solution que je cherche.
Je me suis connecté à distance (SSH) sur cette machine et j'ai lancé mes scripts Shell et Perl. Les scripts Shell, s'exécutent sans problèmes, par contre les scripts "Perl" n'ont pas accès aux var d'env de /etc/bash.bashrc, mais ils ont accès à celles du fichier /root/.bashrc.
PS: Tous ces scripts sont censés être lancés par la crontab.

[dmganges]

Je me suis connecté à distance (SSH) sur cette machine et j'ai lancé mes scripts Shell et Perl. Les scripts Shell, s'exécutent sans problèmes, par contre les scripts "Perl" n'ont pas accès aux var d'env de /etc/bash.bashrc, mais ils ont accès à celles du fichier /root/.bashrc.

Pas clair pour moi
En SSH il y a effectivement connexion, les variables d'environnement devraient être générées...

Colle ici le code Perl, au minimum la partie accès aux variables d'environnement.
Y a-t-il des messages d'erreur ? SI OUI colle-les...
Bref donne-nous du grain à moudre sinon on y arrivera pas !
Parce que là :

les scripts "Perl" n'ont pas accès aux var d'env de /etc/bash.bashrc, mais ils ont accès à celles du fichier /root/.bashrc

je ne comprends pas ce que ça veut dire...

SINON :

PS: Tous ces scripts sont censés être lancés par la crontab.

Là promis les variables d'environnement ne seront pas générées !

Un exemple parmi d'autres :

Tu crées un fichiers qui contient les nouvelles variables.
Je prends un vieux machin, ex :

$HOME/perl/env_perso :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
export ORACLE_BASE=/ORACLE
export ORACLE_TERM=vt320
export TK2DEV=vt320
export NLS_LANG=French_France.WE8ISO8859P1
export TNS_ADMIN=/etc
export NLS_DATE_FORMAT='DD/MM/YYYY'
export NLS_DATE_FORMAT
export ORACLE_HOME=/ORACLE/product/7.3
export SQLPATH=/ORACLE/product/7.3/dbs
export ORA_NLS=/ORACLE/product/7.3/ocommon/nls/admin/data
export PATH=$PATH:/ORACLE/product/7.3/bin
export ORACLE_SID=bsiR
#
echo "ATTENTION ORACLE_SID="$ORACLE_SID

que tu mets par ex $HOME/perl de toutes les machines.

Dans les bash.bashrc de toutes les machines tu ajoutes, à la fin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
...
# Uncomment to use the terminal colours set in DIR_COLORS
# eval "$(dircolors -b /etc/DIR_COLORS)"

#AJOUT
. /home/Michel/perl/env_perso

NB : Le point suivit d'un espace DEVANT qui va faire en sorte que les variables soient initialisées dans l'environnement

Ainsi lorsque les utilisateurs se connecteront les variables ajoutées seront initialisées.

Dans le programme Perl qui sera lancé par cron, il suffira de se servir du fichier $HOME/perl/env_perso pour faire l'initialisation :

$HOME/perl/env.pl

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#!/usr/bin/perl --
use strict;
use warnings;
use utf8;
 
#my $FileEnv = '/proc_perso/env_perso';
 
my $FileEnv = 'env_perso';
my $Fh;
 
open($Fh,'<:utf8', $FileEnv)
	or die Ano("Erreur ouverture fichier environnement : $FileEnv : \n\t $! \n");
 
while ( my $ligne = <$Fh> ) {
	last if ($ligne =~ /^#/);
	my @Elem = split (/ /, $ligne);
	my ($Var, $Valeur) = split (/=/, $Elem[1]);
	$ENV{$Var} = $Valeur;
}
 
print "$ENV{ORACLE_SID}\n";
close $Fh;
 
 
# PUIS LE RESTE DE TON PGM...

PS : Avec Cygwin j'ai qq pb de chemin de fichier que je n'ai pas résolu pour l'instant...
Mettre les fichiers dans un $HOME n'est pas pertinent !
Il faudrait mettre tout çà à la racine dans un nouveau répertoire pour ne pas véroler le reste...
/proc_perso/env_perso
/proc_perso/perl/env.pl
modifier bash.bashrc en conséquence...

[Lolo78]

Le scipt Perl est lancé par la commande "Perl" dans la crontab de l'utilisateur root.

Il y a une chance non négligeable que ce soit l'origine du problème. Les programmes lancés dans le crontab s'exécutent rarement dans le même environnement que ceux lancés depuis un terminal interactif, les variables d'environnement sont rarement disponibles.

Question 1: as-tu le même problème si tu lances ton Perl depuis une session interactive?

Question 2: si tu lances un petit shell de test depuis la crontab et affiches quelques variables d'environnement, qu'obtiens-tu?

Question 3: peux-tu facilement remplacer le lancement du Perl parle lancement d'un shell lançant le Perl? Que se passe-t-il si tu fais cela? Que se passe-t-il si tu fais cela en commençant pas sourcer le fichier bash qui définit les variables voulues?

C'est ce que je veux faire mais je ne sais pas comment le faire. Je ne connais pas trop Perl.

S'il faut lire les fichiers de config dans le script Perl, on verra plus tard, on t'aidera pour ça si c'est nécessaire. Mais je suis à peu près sûr qu'on doit pouvoir y arriver sans passer par là, en gérant correctement l'export des variables d'environnement.

[Philou67430]

Il y a une chance non négligeable que ce soit l'origine du problème. Les programmes lancés dans le crontab s'exécutent rarement dans le même environnement que ceux lancés depuis un terminal interactif, les variables d'environnement sont rarement disponibles.

C'est exactement ce que j'aurais dit. D'ailleurs, la lecture du manuel de cron (man crontab) semble le confirmer. Je suppose que tu ne peux pas définir les variables d'environnement qui sont dans /etc/bash.bashrc dans ton fichier crontab ?

[liloulinx]

Bonjour.
Désolé un peu pour ce retard car j'ai dû me concentrer et terminer mes scripts Shell.

S'il faut lire les fichiers de config dans le script Perl, on verra plus tard, on t'aidera pour ça si c'est nécessaire. Mais je suis à peu près sûr qu'on doit pouvoir y arriver sans passer par là, en gérant correctement l'export des variables d'environnement.

Finalement pour résoudre ce pb,

1. J'ai créé un fichier de definition de var d'env (ex. /root/var_env_mon_projet.txt), qu'utilisent également mes scripts bash.
2. Je source ce fichier dans /root/.bashrc
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   source /root/var_env_mon_projet.txt

3. J'initialise les var de mon script perl à partir de celles du fichier des var d'env avec le mot clé ENV.
   ex.
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   my $PORTSSH = $ENV{'PORTSSH'};

   Puis je continue à utiliser ces variables comme d'hab.

Le problème persiste. L'exécution manuelle du script est OK mais pas celle de la crontab, même quand j'ajoute dans la crontab une ligne du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

*/1 * * * * /bin/bash -c 'source /root/var_env_mon_projet.txt'

!

[dmganges]

Bonjour,
je ne comprends pas l'expression :

Je source ce fichier dans /root/.bashrc

Mais peu importe...

Comment lances-tu le script Perl dans le cron ?

Je ne comprends pas non plus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

*/1 * * * * /bin/bash -c 'source /root/var_env_mon_projet.txt'

Bref, je ne suis pas doué

Tu as au minimum 2 possibilités :

1)
Dans le script Perl au lieu d'évaluer les variables d'environnement par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

my $PORTSSH = $ENV{'PORTSSH'};

tu évalues les variables en lisant le fichier /root/var_env_mon_projet.txt

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
my $FileEnv = '/root/var_env_mon_projet.txt';
my $Fh;
 
open($Fh,'<:utf8', $FileEnv)
	or die Ano("Erreur ouverture fichier environnement : $FileEnv : \n\t $! \n");
 
while ( my $ligne = <$Fh> ) {
	last if ($ligne =~ /^#/);
	my @Elem = split (/ /, $ligne);
	my ($Var, $Valeur) = split (/=/, $Elem[1]);
	$ENV{$Var} = $Valeur;
}
 
print "$ENV{PORTSSH}\n";
close $Fh;

Cette méthode évite d'avoir un script Perl pour l'environnement de connexion et un autre pour l'environnement cron...


2)
Dans le cron :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

*/1 * * * * /bin/bash /root/ScriptCron

et dans /root/ScriptCron :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
. /root/var_env_mon_projet.txt
/usr/bin/perl /home/lioulinx/ScriptPerl.pl

Tu dois comprendre que lorsque tu es connecté, tu es dans un shell (une coquille)
Au moment de la connexion :
/etc/profile
~.profile
~.bashrc

ont renseigné DIFFÉRENTES variables d'environnement qui sont visibles aux scripts Unix/Linux, Perl... ... qui s'exécutent DANS la COQUILLE


En cron pas de COQUILLE !
C'est à toi TOUT SEUL à valuer les variables !
PIRE : tu n'as même pas $PATH !!!

Ça veut dire que dans les scripts que tu places dans le cron tu dois avoir les chemins de fichiers COMPLETS en DUR !!! d'où :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
. /root/var_env_mon_projet.txt
/usr/bin/perl /home/lioulinx/ScriptPerl.pl

Ainsi tu encapsules les variables d'environnement ET le script Perl dans une PSEUDO COQUILLE que s'appelerio /root/ScriptCron

Je n'ai pas le temps de faire un essai :
a) je ne me souviens plus si dans ce cas le POINT TOUT SEUL (première ligne) est nécessaire (en tout cas il ne devrait pas manger de pain...)
b) A l'erreur de Copier/Coller prêt ça devrait être bon

[Lolo78]

D'accord avec les solutions proposées par dmganges. ++.

[liloulinx]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
. /root/var_env_mon_projet.txt
/usr/bin/perl /home/lioulinx/ScriptPerl.pl

Re-bonjour, et Merci pour votre réponse.
J'ai testé votre 2nde solution qui est simple à mettre en œuvre et ça marche. Normalement elle doit fonctionner en tant que telle, mais j'ai dû modifier le "." en "source" dans la 1ère ligne du fichier cron pour qu'elle fonctionne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
source /root/var_env_mon_projet.txt
/usr/bin/perl /home/lioulinx/ScriptPerl.pl

PS:

• "source " est équivalent a ".". Au lieu de faire "source ./script.sh", on peut faire ". ./script.sh".
• La commande "source" lit et exécute les commandes contenues dans le fichier qui lui a été donné comme argument, sans créer de sous-shell. Il modifie donc directement l'environnement du Shell courant. C'est pour cela que les variable déclarées dans le fichier donné en argument à la commande source peuvent être utilisées par le 2ième script (ou le script qui intègre cette commande source).

[dmganges]

"source " est équivalent a ".". Au lieu de faire "source ./script.sh", on peut faire ". ./script.sh".
La commande "source" lit et exécute les commandes contenues dans le fichier qui lui a été donné comme argument, sans créer de sous-shell. Il modifie donc directement l'environnement du Shell courant. C'est pour cela que les variable déclarées dans le fichier donné en argument à la commande source peuvent être utilisées par le 2ième script (ou le script qui intègre cette commande source).

OK, MERCI, j'étais resté à la vieille méthode : ". ./script.sh"

Sinon :
- il vaudrait mieux éviter l'extension .txt pour des scripts shell et préférer .sh voire rien, surtout pour les personnes qui viendront après toi... même si tu choisis des noms significatifs...
conserver .txt pour les recettes de cuisine, les états d'âme...

- également éviter de placer tes scripts perso dans les répertoires de l'OS. Faire un répertoire spécifique pour l'administration /Admin
Ainsi lorsque tu fais une migration de système ou l'installation d'un nouveau serveur tu n'a pas à gratter dans tous les répertoires de l'OS et risquer d'en oublier... les perdre...
Éventuellement monter ce répertoire /Admin en nfs sur toutes les machines que tu administres, c'est confortable de retrouver l'ensemble de ses outils qui fonctionnent partout de la même façon...

- enfin sur d'autres forums tu te ferais écorché vif à travailler directement sous root
Perso j'ai fait ça pendant 20 ans et je continue même si maintenant c'est pour rire,
je ne te lancerai donc pas la première pierre, on est administrateur ou on ne l'est pas, on prend ses précautions et ses responsabilités...
ET plus on casse, plus on apprend

[liloulinx]

Merci pour les conseils. ;-)