BreizFenrir Posté(e) le 19 novembre 2007 Partager Posté(e) le 19 novembre 2007 Si je suis ici c'est parce que je suis bloqué depuis deux demi-journées sur un petit truc très chiant, les tenants et aboutissants duquel je n'arrive pas à comprendre. Je travaille en ce moment sur un script bash me permettant de copier via une seule commande un certain nombre de dossiers ou fichiers que ce soit, dans un autre dossier "local" (je mets les guillemets parce que les disques distants montés via Samba ne sont pas vraiment locaux, mais c'est tout comme pour mon script) ou via SSH. Ce script lit en fait un fichier contenant la liste des dossiers à copier, leur destination et la manière dont la copie doit être faite. Jusque là, rien de trop complexe, et pour ce qui est des copies "locales", ça fonctionne très bien. Par contre, dès que SSH est utilisé, après la première utilisation de ce dernier, ma boucle (pour la lecture ligne par ligne du fichier de configuration) ne fait pas d'autre itération (mais l'itération en cours finit de s'exécuter), quand bien même il reste des lignes à lire. Voila une version très simplifiée de mon code reproduisant le problème (l'appel à SSH a entre autres été simplifié, changez le nom du serveur et rajoutez un nom d'utilisateur au besoin si vous voulez le tester). #!/bin/bash # Test script of an ssh call in a while read loop # # Should show: # ~ -- Done # ~/_doc -- Done taskfile="# Comment rien fs ~ ssh server ~/_doc ssh server" while read fold prot serv; do if [[ ! -z $fold && "${fold:0:1}" != "#" && "$prot" = "ssh" ]]; then ssh $serv "ls -l" > res.out echo "$fold -- Done" fi done < <(echo "$taskfile") Ce code n'affiche qu'une seule ligne au lieu des deux attendues. L'appel à ssh a une influence sur l'instruction read utilisée pour boucler, mais je n'arrive pas à voir quelle en est la raison et comment éviter une telle chose. Je vais continuer mes recherches, et si je trouve une solution avant que quelqu'un d'autre la fournisse, je vous en ferais part. Merci d'avance. Edit : Le code étant touché par ce problème utilise aussi scp. Or, quand scp est utilisé au lieu de ssh dans le code ci-dessus (pas en vue d'obtenir un listing de dossier bien évidemment), le parcours se fait bien ; aucun problème ne se pose. Edit 2 : La solution, très conne, est de modifier le code donné plus haut en redirigeant l'entrée standard au moment de l'appel à ssh vers /dev/null. ssh consomme ce qui est disponible en entrée standard sinon. Par contre je n'ai aucune idée de ce qu'il en fait, n'ayant vu aucun message d'erreur affiché dans la console (je ne suis pas allé voir les log par contre, j'aurais sans doute dû). Lien vers le commentaire Partager sur d’autres sites More sharing options...
tsubasaleguedin Posté(e) le 23 novembre 2007 Partager Posté(e) le 23 novembre 2007 Une question pour un gourou du shell ^^" Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 12 décembre 2007 Partager Posté(e) le 12 décembre 2007 juste une question bête et qui ne mange pas de pain : j'ai un peu l'impression que tu te refais un rsync en moins bien, non ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
BreizFenrir Posté(e) le 14 décembre 2007 Auteur Partager Posté(e) le 14 décembre 2007 juste une question bête et qui ne mange pas de pain : j'ai un peu l'impression que tu te refais un rsync en moins bien, non ? C'est sans doute à peu près ça. Enfin bon depuis que j'ai résolu le problème dont je parle ici je n'ai plus vraiment touché au code. C'est très limité au final mais ça m'a au moins permis d'apprendre des trucs. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.