Discussion :

[pleiade]

Bonjour,

Je traite un retour de commande sous forme de chaîne de ce genre là :

Job Status : RUN OK
Runtime : 06/01/2008 12:00:00
ligne 3
ligne 4

Et j'utilise la fonction grep pour récupérer la première ligne, soit :

$retour=$(cmd.ksh | grep -i "Job Status" 2>&1)

Cela marche très bien pendant 3 ans et courant de l'été 2008, $retour prend une chaîne vide...

Je cherche à comprendre pourquoi, j'espère que vous aurez des idées.

Éléments de recherche :
* La commande marche très bien sur tout les environnements sauf un.
* La commande ne marche pas dans le traitement général de l'application
=> si je l'exécute par un script en dehors du programme ça marche (par putty)
* Si j'exécute deux fois cette ligne dans le traitement, la deuxième exécution marche.
* La mise en place d'un sleep avant la commande n'a rien changé
* Les versions de grep et du shell sont les mêmes sur tout les environnements.

Actuellement j'ai résolu le problème en remplaçant le grep par un head.
Mais le mystère reste entier quant au pourquoi de ce comportement.
Sur un serveur windows je ne m'étonnerais pas trop mais là ...

Merci de votre aide.
N'hésitez pas si vous avez des questions.

Pierre

[mcoolive]

Moi je ne vois pas d'erreur dans cette ligne.

Peut-être il y a une erreur autre bien avant et que la commande head ne renvoie pas non plus ce qu'il faut.

Est-ce que tu as monitoré la sortie de cmd.ksh ? Tu devrais essayer de poser un T (commande tee).

Code :

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

1
2
 
cat fic | tee /tmp/$$.tmp | qqchose

[JeitEmgie]

Bonjour,

Je traite un retour de commande sous forme de chaîne de ce genre là :

Job Status : RUN OK
Runtime : 06/01/2008 12:00:00
ligne 3
ligne 4

Et j'utilise la fonction grep pour récupérer la première ligne, soit :

$retour=$(cmd.ksh | grep -i "Job Status" 2>&1)

Cela marche très bien pendant 3 ans et courant de l'été 2008, $retour prend une chaîne vide...

Je cherche à comprendre pourquoi, j'espère que vous aurez des idées.

Éléments de recherche :
* La commande marche très bien sur tout les environnements sauf un.
* La commande ne marche pas dans le traitement général de l'application
=> si je l'exécute par un script en dehors du programme ça marche (par putty)
* Si j'exécute deux fois cette ligne dans le traitement, la deuxième exécution marche.
* La mise en place d'un sleep avant la commande n'a rien changé
* Les versions de grep et du shell sont les mêmes sur tout les environnements.

Actuellement j'ai résolu le problème en remplaçant le grep par un head.
Mais le mystère reste entier quant au pourquoi de ce comportement.
Sur un serveur windows je ne m'étonnerais pas trop mais là ...

Merci de votre aide.
N'hésitez pas si vous avez des questions.

Pierre

remplacez "cmd.ksh" par le chemin complet de la commande…
si cela résoud le problème cela identifiera le coupable :

$PATH n'est pas correct dans certaines circonstances…

[jmelyn]

Je pense que la commande head est bien plus sûre. Il serait d'ailleurs intéressant de voir ce que le retour de head donne pour l'environnement qui ne fonctionne pas: est-ce le programme qui ne renvoie pas ce qu'il devrait (la première ligne n'est pas le "Job Status" attendu, par exemple parce que le programme renvoie "Job status") ou est-ce la commande grep qui marche mal?

[pleiade]

re-Bonjour,

Merci pour vos réponses rapides.

Je suis sûr et certain du retour et de son format, il s'agit de programmes édités par des maisons dont c'est le métier et de scripts largement éprouvés que j'ai testé dans tout les sens.

On est jamais trop prudent me direz vous.

L'idée du $PATH me parait intéressante, le grep cacherait le plantage de la commande.

Il y a des conditions particulières et connues pour lesquelles le $PATH puisse sauter ou être modifié ?
Je vais chercher de ce coté.


Le head résout en effet le problème, il marche sur tout les environnements.
J'ai penser à une erreur de grep mais c'est quand même une fonction basique ultra utilisée... Et puis cela marche dans certains cas...

[jmelyn]

Pour tracker une erreur, il faut être méthodique et systématique. Donc:

Dans l'environnement qui ne fonctionne pas, cmd.ksh est-il réellement lancé (effets de bord visibles, comme une création de fichier)? Si oui quelle est la chaine renvoyée (echo $retour, sans filtre grep ou head), si non il faudrait mettre le chemin complet du script: /path/to/cmd.ksh.

[pleiade]

Non, pas d'effet de bord.

il s'agit d'un environnement de production, j'ai deux fenêtres d'installation dans le mois et je ne peux pas me permettre de tenter un test sans certifier une non-aggravation de la situation.

j'ai fait le test suivant le mois dernier :
retour=$(cmd.ksh | grep -i "Job Status" 2>&1)

test1=$(cmd.ksh | head -1 2>&1)

test2=$(cmd.ksh 2>&1)
test2=`echo $test2 | cut -c 0-32`

Résultat :
(fctDonnerStatusJob) Retour grep : {}
(fctDonnerStatusJob) Retour head : {Job Status : RUN OK (1)}
(fctDonnerStatusJob) Retour cut : {Job Status : RUN OK (1) Job Cont}

cmd.ksh est donc bien lancé et fournit le résultat attendu.

D'un coté je ne vois pas trop le PATH changer tout d'un coup pile entre deux lignes à chaque appel de ces lignes (plusieurs fois par jour)...
cmd.ksh ne modifiant pas le PATH enfin pas que je sache. A voir

[jmelyn]

Il est quasiment impossible de deviner le problème, ça peut être une multitude de choses.

• Tu dis qu'à la deuxième tentavive d'exécution, ça marche. Donc ce n'est pas la commande head qui corrige, mais le fait de relancer le programme.
• Il faudrait savoir si le programme cmd.ksh est vraiment lancé la première fois.

Pas d'idée pour l'instant. J'imagine récupérer le PID mais comment faire sans interférer avec la sortie standard? Tu utilises ksh, n'est-ce pas? Sur quel système?

[pleiade]

Actuellement le head corrige le problème, il n'y a que lui qui est appelé (une seule fois) et cela marche... cmd.ksh marche donc bien, le PATH aussi...

J'utilise ksh oui sur un AIX Version 5.2

J'épluche les PATH de mon système c'est la jungle mais ca devrait marcher.
J'espère récupérer le PATH courant lors du traitement ce qui n'est pas évident sans changer les scripts et mettre un echo dans le traitement.


Rien n'est logique dans ce problème. L'architecture de l'application est tellement complexe...

Voilà des semaines que je démonte chacune de mes théories...
Merci pour ton investissement

[pleiade]

Bonsoir,

J'ai le plaisir de vous écrire pour mettre fin à cette discution.

En suivant vos idées sur les PATH, je suis arrivé non sans mal à la cause de ces comportements bizarres.

La variable $PATH était modifié plusieurs fois et dans un ordre sans logique ni chronologie fixe dans le traitement. Ce qui explique le comportement aléatoire du problème.

Et un fichier avec les droit d'exécution répondant au doux nom de 'grep' est apparu dans le dossier des exécutables de l'application. (fichier qui était vide)

Le PATH étant modifié en live par l'application, parfois /usr/bin était le premier chemin valide pour grep, parfois il s'agissait du dossier de l'application.
Il va falloir clarifier ce PATH.

Il reste toujours des pourquoi sans réponse, mais ce n'est plus du ressort de ce forum.

Merci encore à vous.