Discussion :

[nicolas.pailheret]

Bonjour à tous,

J'ai un problème de "durée de vie" de variable entre 2 sessions lors de l'appel d'un script shell sous Unix.

Voilà grosso modo le soucis :

je me connecte sur ma machine UNIX avec un USER "A" afin de lancer un script shell

Ce script, entre autre, fait appel à une sorte de "fonction", qui est en fait un outil Oracle qui permet de faire une requête auprès d'une base Oracle, et de lancer un traitement au sens Oracle Applications (traitement Oracle comptable)

Le principe est le suivant :


1) Connexion sous UNIX avec le USER "A"
2) Appel du script : script.sh -> entrée
3) Au sein du script : appel d'une "fonction" CONCSUB qui admet en paramètre, en argument si on veut, entre autres, un nom de traitement à lancer sous Oracle, les paramètres du traitement, etc et surtout : la connexion auprès des bases Oracle avec un USER "B" (cf. code, ce USER est "APPS") :

Code :

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

1
2
 
Retour=`CONCSUB \$APPS_USER/\$APPS_PASS $LG_RESP_SHRTNM "$LG_RESP" $LG_USER WAIT=10 CONCURRENT $LG_APPLI $LG_PROG $PROGPAR1

Ma question est :
si en amont de l'appel de la fonction concsub dans le script shell une variable $REP est déclarée, y'a-t-il un moyen pour qu'au moment de l'appel de concsub, et donc du changement de session de USER "A" vers USER "B" ("APPS"), cette variable soit encore disponible.

Pour le moment les seules actions que j'effectuent sont (avant appel de la fonction):

Code :

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

1
2
3
 
export $REP=Chemin quelconque
CONCSUB...

Mais c'est largement insuffisant...

On m'a parlé de placer cette fameuse variable "$REP" dans un fichier qui lui serait accessible par les différents USER, mais honnêtement étant loin d'être expert en shell je vois mal comment faire en sorte qu'au moment de l'appel de concsub (et vu comment on s'en sert) faire en sorte que "APPS" aille disposer de(s) variable(s) présentes dans un éventuel fichier qu'on aurait créé...


Voilà, je sais pas si ce problème est exposé clairement, si il inspire qqun (forcément un cas déjà vu qqpart par qqun...!)

Merci en tout cas d'avance pour les réponses, moi je reste à l'affut des messages pour apporter plus de détails sur le pb en lui-même.

A+
Nico

[Sve@r]

Arf, problème un peu confus donc je vais résumer
La question, à ce qu'il me semble, est de dire si une variable créée par un processus A peut être connue du processus B

La réponse de base est non. Unix crée l'indépendance totale entre les processus. C'est une des raisons qui font que tout virus reste et restera sans effet sur Unix.
Cependant il existe une exception à cette règle: c'est quand le processus B a été généré par le processus A. Et à condition qu'il ait fait un export de sa variable, alors le processus B en recevra une copie. Bien évidemment toute modification de la copie par le processus B reste sans effet sur la variable d'origine.

Il existe aussi des outils de communication entre processus. L'outil de base est le fichier texte. Le processus A écrit dans un fichier texte ses data et le processus B va lire le fichier texte.
Il existe aussi le fichier pipe qui est conçu pour ça. L'avantage par rapport au fichier texte est que le pipe est bloquant (si un processus écrit dedans, il sera bloqué jusqu'à ce qu'un autre aille lire les data écrites) et que la lecture des data les fait automatiquement disparaitre du pipe.

Que ce soit dans un fichier texte ou dans un pipe, la façon d'écrire est toujours la même => echo
Et la façon de lire peut être le simple read data < fic mais si le fichier contient plusieurs lignes, on pourra utiliser une boucle de lecture

Code :

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

1
2
3
4
5
exec 3<fichier_a_lire      # Création d'un canal contenant le fichier
while read lig 0<&3          # Saisie d'une variable "lig" dont l'info sera prise dans le canal 3 - Si le canal est vide, le read renvoie faux et le while s'arrête
do
    echo "$lig"
done

[nicolas.pailheret]

Merci Sve@r!

A chaque fois tu réponds présent pour un aiguillage efficace vers un début de solution

Je garde du coup en mémoire les explications théoriques sur la durée de vie d'une variable, et également les lignes que tu as donné pour ce qui d'aller récupérer une ligne dans un fichier...
Il me reste avec ma "contrainte" qui est l'utilisation d'une fonction (ce fameux "outil" concsub auquel je fais appel dans le script) de trouver le moyen de lui passer les lignes que tu m'as donné pour que je puisse aller lire ma variable $REP.

Une dernière ptite question : j'ai testé très simplement les lignes que t'as donné : ça ne renvoie que les 2 premières lignes du fichier "fichier_a_lire"? c'est normal?

Merci encore,
A+
Nico

[Sve@r]

Une dernière ptite question : j'ai testé très simplement les lignes que t'as donné : ça ne renvoie que les 2 premières lignes du fichier "fichier_a_lire"? c'est normal?

Non.

Code :

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

1
2
3
4
5
6
#!/bin/sh
exec 3</etc/passwd
while read lig 0<&3
do
    echo "$lig"
done

Ca, ça me donne tout le fichier complet.

Il me reste avec ma "contrainte" qui est l'utilisation d'une fonction (ce fameux "outil" concsub auquel je fais appel dans le script) de trouver le moyen de lui passer les lignes que tu m'as donné pour que je puisse aller lire ma variable $REP.

Rhaa j'ai raté un truc
1) comment tu remplis cette variable "REP"
2) quel est son rôle pour concsub
???

[nicolas.pailheret]

Salut Sve@r

Désolé de ne pas être revenu plus tôt


Pour ce qui est de concsub et de la variable REP :

au sein du shell que j'exécute, je fais appel à ce truc "concsub"

de mon point de vue, c'est juste une fonction qui permet de se connecter aux bases oracle, et de lancer un "traitement" (= un programme)
concsub, vue en tant que fonction, demande en argument entre autre le nom du programme à lancer...
(faut vraiment voir ça comme si tu faisais appel à une fonction "somme" et qu'en argument si tu donne 2 et 2 ça renvoie 4, là dans ce cas tu donnes le nom d'un programme, la requête s'effectue et sous oracle tu vois le traitement en question qui se lance)

Par contre, le programme en question est donc encapsulé dans ce shell, et pour moi ce traitement est une boite noire-> je n'ai pas la main sur ce qu'il fait,e tc.

Tout ce que je sais, c'est qu'en "dur" au niveau du source de ce programme "boite noire", a été codé un chemin qui dit au programme pour simplifier "tu as besoin d'un fichier à lire, il est dans le répertoire CHEMIN, si $REP existe, alors au lieu d'aller dans CHEMIN, va voir dans $REP en premier"

Et c'est cette variable $REP que je renseigne dans mon script, comme ça dès l'appel à concsub, le programme donné en paramètre de concsub est censé aller voir dans $REP plutot que CHEMIN, comme prévu.
Or, à l'appel de concsub, pour l'aspect requête auprès d'oracle, une connexion se fait avec un autre user et mdp. Et c'est là que la bât blesse et que la variable $REP "meurt"
Donc le programme "boite noire" ne trouvant pas $REP, va donc par défaut dans CHEMIN.
Mais comme je ne peux rien faire comme action au niveau de concsub (genre en plus de ce concsub fait habituellement, ajouter la lecture d'un fichier qui contiendrait $REP), je suis entrain de me demander si c'est tout bonnement impossible...

Merci !
A+ Nico

[Sve@r]

Salut Sve@r

Désolé de ne pas être revenu plus tôt


Pour ce qui est de concsub et de la variable REP :

au sein du shell que j'exécute, je fais appel à ce truc "concsub"

de mon point de vue, c'est juste une fonction qui permet de se connecter aux bases oracle, et de lancer un "traitement" (= un programme)
concsub, vue en tant que fonction, demande en argument entre autre le nom du programme à lancer...
(faut vraiment voir ça comme si tu faisais appel à une fonction "somme" et qu'en argument si tu donne 2 et 2 ça renvoie 4, là dans ce cas tu donnes le nom d'un programme, la requête s'effectue et sous oracle tu vois le traitement en question qui se lance)

Ouaip. C'est pas facile à comprendre cette histoire de somme(2,2)=4 (s'agit-il de 2*2, 2*2 ou 2² toute la question est là) mais bon, je fais des efforts surhumains pour ne pas perdre le fil...

Tout ce que je sais, c'est qu'en "dur" au niveau du source de ce programme "boite noire", a été codé un chemin qui dit au programme pour simplifier "tu as besoin d'un fichier à lire, il est dans le répertoire CHEMIN, si $REP existe, alors au lieu d'aller dans CHEMIN, va voir dans $REP en premier"

Ok. Tu fais appel à un programme Oracle "boite_noire" qui a besoin d'une variable "REP" et pas autre chose. Si tu appelles ce programme directement, ça ira. Mais toi tu passes par un programme intermédiaire "concsub" qui appelle ce programme "boite_noire" à ta place et là, manque de bol, concsub génère un environnement totalement neuf dans lequel il n'y a pas de variable "REP". C'est ça ???

Or, à l'appel de concsub, pour l'aspect requête auprès d'oracle, une connexion se fait avec un autre user et mdp. Et c'est là que la bât blesse et que la variable $REP "meurt"
Donc le programme "boite noire" ne trouvant pas $REP, va donc par défaut dans CHEMIN.
...
Mais comme je ne peux rien faire comme action au niveau de concsub (genre en plus de ce concsub fait habituellement, ajouter la lecture d'un fichier qui contiendrait $REP), je suis entrain de me demander si c'est tout bonnement impossible...

Tu as dit que tu passais à concsub le nom du programme à appeler. J'imagine que ça doit être un truc ressemblant grosso-modo à ceci

Code :

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

1
2
#!/bin/sh
concsub "/usr/local/oracle/boite_noire"

Et là, tu dis que concsub génère un sous-processus pour appeler la boite_noire. Pourquoi ne pas essayer de mettre la variable dans le sous-processus, style

Code :

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

1
2
#!/bin/sh
concsub "export REP=/home/machin; /usr/local/oracle/boite_noire"

???