Variable Pérenne inter session

Version imprimable

26/05/2009, 16h03
nicolas.pailheret

Variable Pérenne inter session
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:

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:

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

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:

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

27/05/2009, 16h39
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
28/05/2009, 00h01
Sve@r
Citation:

Envoyé par nicolas.pailheret

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:

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.

Citation:

Envoyé par nicolas.pailheret

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
???
29/05/2009, 12h05
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
30/05/2009, 15h21
Sve@r
Citation:

Envoyé par 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)

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...

Citation:

Envoyé par nicolas.pailheret

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 ???

Citation:

Envoyé par nicolas.pailheret

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:

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:

1 2 #!/bin/sh concsub "export REP=/home/machin; /usr/local/oracle/boite_noire"
???
04/06/2009, 14h21
nicolas.pailheret

Bonjour Sve@r

Désolé pour la latence pour les réponses.

Je ne cherchais absolument pas à te froisser par le détail sur la fonction!
C'était simplement pour faire passer l'idée qu'utiliser l'astuce qui consiste en procéder comme ça :
concsub "export REP=/home/machin; /usr/local/oracle/boite_noire" ne peut pas fonctionner.

Le mieux apparement reste de créer un fichier qui serait accessible lors de l'appel de concsub... mais je vois pas comment faire,

Je vous tiens au courant dès que j'aurais une solution satisfaisante

Merci encore pour les réponses, bonne journée
04/06/2009, 16h38
Sve@r

Citation:

Envoyé par nicolas.pailheret

Je ne cherchais absolument pas à te froisser par le détail sur la fonction!

Non, je blaguais

Citation:

Envoyé par nicolas.pailheret

C'était simplement pour faire passer l'idée qu'utiliser l'astuce qui consiste en procéder comme ça :
concsub "export REP=/home/machin; /usr/local/oracle/boite_noire" ne peut pas fonctionner.

Arf là ça m'étonne. Si concsub génère un environnement spécifique pour exécuter le code qu'il a en paramètre, si ce code est "export REP=truc; autre_programme" il est quasiment certain que l'autre_programme lancé par concsub() connaitra la variable REP puisque celle-ci aura été définie dans le même espace d'exécution. Y a-t-il un message d'erreur ???

A tout hasard, ceci...concsub "(export REP=/home/machin; /usr/local/oracle/boite_noire)" avec des parenthèses pour forcer le groupement des 2 instructions dans le même processus... Ou alors ceci: concsub "(REP=/home/machin; export REP; /usr/local/oracle/boite_noire)" juste au cas où l'espace d'exécution serait un shell vraiment de base qui ne connaitrait pas la syntaxe export var=valeur...
09/06/2009, 12h29
nicolas.pailheret
Salut Sve@r!

Ok merci pour les infos j'ai fini par m'en sortir d'une manière un peu bancale mais qui suffit visiblement en suivant ta méthode de forcer à l'aide parenthèses...

Tiens pour info dans ce genre de manip (mais ça n'a rien à voir directement) entre autre de paramètres donnés à concsub, je passais la date (du lendemain) que je calculais très "bêtement" comme ça
Code:

1 2 3 AJOURDUI=$(date +%d) LEND=$((AJOURDUI+1))
Mais arrivé au 08 juin, je me suis retrouvé confronté à un classique du shell (visiblement) : ./essai.sh: line 131: 09: value too great for base (error token is "09")
Ahah! le calcul arithmétique considère qu'un nombre commençant par 0 est en octal, d'après les messages sur les forums!

Ah les joies du shell!

Merci encore Sve@r pour ta dispo et les infos que tu donne!
Bonne continuation
A+
Nico
09/06/2009, 19h31
Sve@r
Citation:

Envoyé par nicolas.pailheret

Salut Sve@r!

Ok merci pour les infos j'ai fini par m'en sortir d'une manière un peu bancale mais qui suffit visiblement en suivant ta méthode de forcer à l'aide parenthèses...

Putain j'ai vraiment dit ça en désespoir de cause. Style
- on a tout essayé Dr House, que peut-on faire de plus ?
- c'est un lupus, traitez-le à l'exomil !
Citation:
Envoyé par nicolas.pailheret

Tiens pour info dans ce genre de manip (mais ça n'a rien à voir directement) entre autre de paramètres donnés à concsub, je passais la date (du lendemain) que je calculais très "bêtement" comme ça

Code:

1 2 3 AJOURDUI=$(date +%d) LEND=$((AJOURDUI+1))

Mais arrivé au 08 juin, je me suis retrouvé confronté à un classique du shell (visiblement) : ./essai.sh: line 131: 09: value too great for base (error token is "09")
Ahah! le calcul arithmétique considère qu'un nombre commençant par 0 est en octal, d'après les messages sur les forums!

Ah les joies du shell!
Arf trop pété de rire. Ca t'apprendra à faire la faignasse
Code:

1 2 AJOURDUI=$(date '+%d') # Les quotes simples aident à protéger efficacement le format LEND=$(expr $AJOURDUI + 1) # Ne passons pas à coté des choses simples
Citation:

Envoyé par nicolas.pailheret

Merci encore Sve@r pour ta dispo et les infos que tu donne!
Bonne continuation
A+
Nico

:ccool: