Forum Programmation.shell SSH "temps-réel"

Posté par  .
Étiquettes : aucune
1
22
juil.
2011

Bonjour,

J'ai un ligne de shell qui ressemble à ça:
ssh -l

La commande est en fait un programme C (sur la machine distante), qui peut durer une dizaine de minutes et balance des printf de temps en temps.
Or, je souhaiterais recevoir ces informations en temps-réel. J'ai l'impression que ma ligne attend d'avoir le code retour de ssh, donc que le programme sur la machine distante soit fini, avant de pouvoir m'afficher les infos. Comment contourner la chose ?

Question subsidiaire: je souhaite ouvrir un xterm, lancer la commande via ssh, et afficher les résultats dans xterm. Pour la moment j'ai ça:
xterm -hold -e "echo | ssh -l " &
ça marche plutôt bien excepté le problème de temps réel.
Comment faire ?

Merci.

  • # unbuffer

    Posté par  . Évalué à 5.

    Peut être un problème de buffering du printf. Une sortie sur stdout va être flushée à chaque retour chariot si elle est dirigée vers une console, mais quand ça lui chante en cas de pipe ou de fichier (même problème pour stderr il me semble).

    La solution: la commande « unbuffer ».

    • [^] # Re: unbuffer

      Posté par  . Évalué à 1.

      Ça serait étonnant car le programme fonctionne normalement si je fais ça en plusieurs étapes (me loguer sur la machine, puis lancer le programme).

      test effectué: ça ne change rien.

    • [^] # Re: unbuffer

      Posté par  . Évalué à 1.

      Je suis un énorme boulet, j'avais compris le message à l'envers, ça fonctionne bien, un grand merci à toi, vraiment.
      Par contre je n'ai pas vraiment compris le pourquoi.

      • [^] # Re: unbuffer

        Posté par  (site web personnel) . Évalué à 1.

        C'est le même genre de problème que quand tu fais un

        tail -f mon_log | grep pattern1 | grep patern2

        Tu a le patter1 qui sort dans le log, qui matche en plus le partern2 mais il ne s'affiche pas dans ton terminal... En fait il est en attende dans un buffer et il faut qu'il y ai eu assez de pattern1 pour que ca déclenche un vidage et envoi dans le deuxieme grep !
        Enfin moi j'ai compris ca comme ca ....

        Je ne connaissait pas "unbuffer" faut que je regarde ca !
        Je résolvais ce genre de soucis a coup de 'flush' dans awk ( ce qui a l'avantage de marcher sur Solaris )

        Fuse : j'en Use et Abuse !

      • [^] # Re: unbuffer

        Posté par  . Évalué à 1.

        « unbuffer » fait croire au programme que la sortie se fait toujours vers une console, même si c'est vers un pipe, donc la partie stdio va flusher à chaque fin de ligne, plutôt que toutes les pages.

      • [^] # Re: unbuffer

        Posté par  (site web personnel) . Évalué à 9.

        Pourquoi :

        Typiquement, lorsque la sortie standard est un terminal, c'est qu'il y a un utilisateur qui regarde, et il est plus confortable pour l'utilisateur de voir la sortie du programme en « temps réel ». De mémoire, stdout est alors bufferisé ligne par ligne, et stderr pas bufferisé du tout (comportement de la GNU libc).

        Lorsque la sortie standard est un autre programme ou un fichier, habituellement on s'en fout d'avoir la sortie au fur et à mesure où elle arrive, et les sorties sont bufferisées avec de plus gros buffers (4k de mémoire, mais à vérifier si tu préfères).

        C'est l'éternelle question de la performance VS l'interactivité...

        • [^] # Re: unbuffer

          Posté par  . Évalué à 1.

          Merci pour cette explication.

  • # fflush

    Posté par  (site web personnel) . Évalué à 1.

    dans ton programme, fait un fflush(stdout); pour forcer l'affichage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.