[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sync sur un seul fichier



Le 25/01/16 à 17:04, Olivier Bitsch <olivier.bitsch@gmail.com> a écrit :

OB> Hello,
OB> 
OB> Alors je ne connaissais pas l'utilisation d'exec dans les scripts bash, et
OB> ça me parrait très pratique (visiblement pour faire de la redirection de
OB> toutes les sorties des commandes d'un script).
OB> 
OB> Je me suis un peu penché sur la question, et effectivement, tant que le
OB> script n'est pas terminé, il semblerait que le fichier $RAPPORT soit
OB> toujours ouvert, et son contenu peut ne pas être sauvegardé (surtout si le
OB> filesystem utilise noatime il me semble). Mais techniquement, même avec
OB> cette option, lorsque le script est terminé, le contenu du fichier $RAPPORT
OB> doit être présent, même si ce dernier n'est pas encore réellement écrit sur
OB> le disque.
OB> 
OB> D'après ce petit guide sur exec :
OB> 
OB> http://wiki.bash-hackers.org/commands/builtin/exec
OB> 
OB> Il faudrait mieux tout mettre ton script dans une fonction (main dans
OB> l'exemple), lancer la fonction et récupérer le résultat dans le fichier de
OB> sortie puis enfin analyser le fichier de sortie.
OB> 
OB> main() {
OB> 
OB>   echo "un truc"
OB> 
OB> }
OB> 
OB> main 2>&1 | while read line; do echo "[$(date '+%F %T')] $line" >> $RAPPORT
OB> ; done
OB> 
OB> 
OB> # si le rapport est non vide on l'envoie
OB> [ -s $RAPPORT ] && mail -s "rapport du $(date +%F)" root < $RAPPORT

Merci pour avoir pointé ça.

Ça va pas être très pratique de reprendre tous mes scripts, mais y'a peut-être pas d'autre
solution.
Si le pb est que le sous-shell n'a pas refermé son fichier, terminer le exec avant d'analyser
$RAPPORT devrait marcher aussi.
Ça simplifie pas tellement mon pb, parce la souvent je continue d'utiliser la capture stdout
après l'envoi par mail (pour confirmer qu'il a été envoyé, éventuellement faire d'autre choses
et avant de sortir concaténer tout ça dans un log global).

En revanche, je m'étonne que le shell principal ne récupère pas les infos qu'un sous-shell
aurait écrites dans un fichier (il me semblait que même si elle n'était pas encore
physiquement écrites sur le disque ça devait fonctionner, mais visiblement c'est pas très
fiable), ou alors ça ne fonctionne que si le sous-shell a terminé et fermé son descripteur de
fichier.

Il me semble aussi avoir lu que c'était même la seule manière d'échanger des valeurs entre
un sous-shell et son parent[1], ça doit être vrai tant que le sous-shell ne tourne pas en tâche
de fond (attendre qu'il ait fini avant de regarder le résultat).

Faudrait que j'essaie en exportant une fct d'écriture (dans mon fichier $RAPPORT) depuis le
script principal vers le sous-shell…

Sinon, y'a peut-être une autre solution en utilisant par un descripteur de fichier en lecture
(écrire dedans plutôt que dans $RAPPORT) ou alors en utilisant un signal pour signifier au
shell parent que l'on a écrit qqchose dans $RAPPORT, mais il faudrait alors fermer le
descripteur qui capture sdtout pour lire le contenu, on tourne en rond (et ça devient une usine
à gaz).

Moralité, la solution que tu mentionnes est probablement la plus simple, quitte à faire
des fcts main1, main2…


[1] on peut s'en sortir en passant par des signaux, je m'en sers parfois mais ça limite le nb
de valeurs différentes que l'on peut passer, le parent ne peut que choisir parmi une liste
connue à l'avance, avec une correspondance signal<=>valeur, pour deux valeurs possible ça
marche bien (j'utilise RTMIN et RTMAX, mais y'en a quelques autres de dispo pour ce genre
d'usage).

-- 
Daniel

Les extrémistes devraient être fusillés.


Reply to: