Discussion :

[daworld]

Salut,

J'ai plusieurs serveurs Linux (RHEL 5.x) chacun ayant plusieurs crontab.

Les commandes lancées sont de ce genre :

Code :

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

* * * * * ksh -c "(. ${HOME}/.profile; commande_ayant_besoin_des_vars_du_profile" 1>/path/1.log 2>/path/1.err

Cela marche partout sauf sur un seul serveur.
Il semblerait que cela soit l'appel du .profile qui ne se fait pas.

J'ai tout vérifier 20fois sans succès.

Une idée?

[daworld]

Salut,

Si cela peut aider, je ne crois pas que cela soit du à l'usage de la crontab.

Dans un shell KSH interactif après valorisation de la variable dans le fichier .profile

Code :

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

export TOTO=TOTO

dans le fichier .profile :

Cette commande donne la valeur :

Code :

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

. $HOME/.profile;echo $TOTO

Celle ci non :

Code :

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

ksh -c ". $HOME/.profile;echo $TOTO"

Merci.

[Sve@r]

Salut,

Si cela peut aider, je ne crois pas que cela soit du à l'usage de la crontab.

Dans un shell KSH interactif après valorisation de la variable dans le fichier .profile

Code :

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

export TOTO=TOTO

dans le fichier .profile :

Cette commande donne la valeur :

Code :

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

. $HOME/.profile;echo $TOTO

Celle ci non :

Code :

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

ksh -c ". $HOME/.profile;echo $TOTO"

Merci.

Salut
Celle-ci non plus

Code :

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

sh -c ". $HOME/.profile;echo $TOTO"

Ce qui signifie que l'option "-c" n'intègre pas la possibilité de sourcer un fichier

Pourquoi ne créerais-tu pas un script "toto.ksh de ce style

Code ksh :

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

1
2
3
#!/bin/ksh
. $HOME/.profile
commande_ayant_besoin_des_vars_du_profile

Puis mettre ta ligne de cron ainsi * * * * * toto.ksh" 1>/path/1.log 2>/path/1.err ???

[Postmortem]

Salut,

Si cela peut aider, je ne crois pas que cela soit du à l'usage de la crontab.

Dans un shell KSH interactif après valorisation de la variable dans le fichier .profile

Code :

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

export TOTO=TOTO

dans le fichier .profile :

Cette commande donne la valeur :

Code :

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

. $HOME/.profile;echo $TOTO

Celle ci non :

Code :

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

ksh -c ". $HOME/.profile;echo $TOTO"

Merci.

Salut,
Et comme ça ?

Code :

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

ksh -c '. $HOME/.profile;echo $TOTO'

Edit :
Je ne peux pas essayer avec ksh mais en bash :

Code :

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

1
2
3
4
5
6
$ cat mes_var
export toto=titi
$ bash -c ". mes_var; echo $toto"
 
$ bash -c '. mes_var; echo $toto'
titi

[jlliagre]

Les commandes lancées sont de ce genre :

Code :

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

* * * * * ksh -c "(. ${HOME}/.profile; commande_ayant_besoin_des_vars_du_profile" 1>/path/1.log 2>/path/1.err

Cela marche partout sauf sur un seul serveur.
Il semblerait que cela soit l'appel du .profile qui ne se fait pas.

J'ai tout vérifier 20fois sans succès.

Une idée?

quel ksh ? pdksh ou ksh93 ?
La commande passée à ksh -c est invalide. Pourrais-tu mettre une vraie commande ?
"ça marche partout sauf sur un seul serveur" n'est pas très précis.
Qu'est-ce qui ne marche pas ? Le script ne se lance pas ? Il y a des messages d'erreur ?
Qu'est-ce qui te fait penser que l'appel au .profile ne se fait pas ?
Qu'est-ce que tu as vérifié vingt fois sans succès ?
Qu'y a-t-il dans 1.log et 1.err ?

[Sve@r]

Salut,
Et comme ça ?

Code :

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

ksh -c '. $HOME/.profile;echo $TOTO'

Super bien vu !!!
Du coup celle-ci sh -c ". $HOME/.profile;echo \$TOTO" fonctionne aussi.
En fait le pb ne vient pas du "-c" mais de ce que les variables sont interprétées par le shell courant avant d'être envoyées au ksh -c..

[daworld]

Salut,
Et comme ça ?

Code :

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

ksh -c '. $HOME/.profile;echo $TOTO'

[/code]

Salut,

Comme cela, ça marche!

Pour jlliagre, désolé de n'avoir pas donnée assez de complément; les voici :

ksh93.
La commande

Code :

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

ksh -c ". $HOME/.profile;echo $TOTO

fonctionne sur d'autres serveurs RHEL 5.7 32bits monté de la même manière. mais pas sur celui sur lequel je travaille en ce moment.

Ce qui me fait penser que cela ne marche pas, c'est que dans sortie standard

Code :

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

1>

(redirigée vers un fichier) le résultat du echo est vide pour les variables contenu dans le .profile et valorisé pour les variables comme le

Code :

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

$PATH

.

J'ai vérifier, par rapport aux serveurs qui fonctionnent, le .profile, le ficher crontab, le ficher /etc/profile, la valeur de la variable $HOME, la valeur du shell par défaut.



Pour finir, cela fonctionne donc à présent avec comme séparateur le ' et non pas le ".
Pourquoi cette différence entre mes serveurs? Y a til un paramètre que j'aurais raté qq part?

Merci

[Sve@r]

Pour finir, cela fonctionne donc à présent avec comme séparateur le ' et non pas le ".

Si tu as bien lu ma réponse, tu sais aussi que ça marcherait avec ta syntaxe initiale mais en protégeant les caractères particulier comme le $ avec un backslash

Pourquoi cette différence entre mes serveurs? Y a til un paramètre que j'aurais raté qq part?

A mon avis, les serveurs sur lequel ça fonctionne sont des serveurs dans lesquels les variables que tu utilises sont déjà initialisées ailleurs que dans le .profile. Et donc elles sont connues du cron.
Et le serveur sur lequel ça ne fonctionne pas est un serveur plus récent, dans lequel il ne reste pas tout un tas de configs issues de tests dans tous les sens. Mais c'est lui qui fait foi...

[jlliagre]

A mon avis, les serveurs sur lequel ça fonctionne sont des serveurs dans lesquels les variables que tu utilises sont déjà initialisées ailleurs que dans le .profile. Et donc elles sont connues du cron.

Ca parait difficilement plausible. cron lance les commande avec un environnement très limité (LOGNAME, HOME, SHELL, PATH et pas grand chose d'autre).

Je chercherais plutôt du coté de $HOME/.kshrc et /etc/ksh.kshrc, chargés au démarrage de ksh, qui n'ont pas l'air d'avoir été vérifiés.

[daworld]

Salut,

Les serveurs sont tous récents et montés par moi.
Pas de configurations antérieurs. Pas de variables initialisées ailleurs.

Par contre, peut être qu'il y a un petit paramètre quelque part qui m'a échappé.

sver, je relis ta réponse et mets ça dans un coin de ma tête.
Sur le serveur où cela fonctionne les commandes sont de ce type :
Pas de variable échappée par \, par contre le nom des variable est toujours protégés par {}. Une piste?

Code :

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

30 22 * * *  /usr/bin/ksh -c "(. ${HOME}/.profile ; unset ORACLE_SID;export TWO_TASK=BASEPROD ; ${HOME}/bin/SCRIPT PARAM1 )" 1>/dev/null 2>/trace/script.err

[jlliagre]

La "protection" par les accolades n'a aucun effet dans l'exemple donné.

La variable HOME est celle initialisée par cron à partir de l'entrée dans la base passwd pour le compte en question, pas celle éventuellement surchargée dans le .profile.

Les parenthèses sont inutiles, on est déjà dans un sous-shell.

[Sve@r]

Sur le serveur où cela fonctionne les commandes sont de ce type :
Pas de variable échappée par \, par contre le nom des variable est toujours protégés par {}. Une piste?

Euh non t'as pas bien compris ce que j'ai dit
Imagine que "var" contienne "toto" => export var=toto.
Si tu écris ksh -c "echo $var", ton shell courant interprète cette instruction et remplace la variable par son contenu. Donc le ksh invoqué exécutera ceci: echo toto.

Maintenant, si tu écris ksh -c 'echo $var' ou bien ksh -c "echo \$var", la variable étant protégée par des simples quotes ou bien par un backslash, elle n'est pas interprétée et est donc transmise telle qu'elle. Donc le ksh exécutera ceci : echo $var.

Il se trouve que dans les deux cas, le résultat affiché sera le même. Mais le comportement amenant cet affichage aura, lui, été différent. Dans le premier c'est ton shell courant qui interprète la variable et dans le second, c'est le ksh fils (qui connait "var" parce qu'elle a été exportée).
D'ailleurs en refaisant le même test mais sans exporter var, alors dans le second cas, rien n'est affiché puisque le fils ne possède pas de variable nommée "var".
Maintenant, cas inverse, imagine que la variable n'existe pas dans ton shell courant. Alors c'est dans le premier cas que rien ne sera affiché puisque le ksh fils n'aura rien reçu. Probable que c'est le cas sur ton serveur.

Les accolades, elles, ont une utilité toute autre. Elles serent à isoler le nom de la variable en cas d'ambiguïté. Comme dans le cas suivant: prix=10; echo "Mon vélo coûte $prixF". Le shell ira essayer de trouver la variable "prixF" inexistante. Pour pallier, tu es obligé de protéger le nom spécifique par des accolades => prix=10; echo "Mon vélo coûte ${prix}F".
Elles servent aussi à faire des opérations "en live" sur les variables, comme cele-ci: echo "Mon vélo coûte ${prix:-50}F" qui est l'équivalent (mais en plus court) à ce bloc conditionnel test -s "$prix" && echo "Mon vélo coûte ${prix}F" || echo "Mon vélo coûte 50F".
Donc les accolades sont pratiques, certes, mais inutiles dans ton problème actuel...

[daworld]

Compris Sve@r, merci!