Forum Programmation.python Récupérer le contenue de kwrited ou écouter /dev/pts/0

• # une raison ?

  Posté par z a le 07 mai 2006 à 20:09. Évalué à 1.

  

  il ne rend pas la main car il n'a rien à lire, non ? C'est ce qu'on appele les fonctions "bloquantes" je crois. Normalement il lira quelque chose quand quelque chose sera écrit dessus, essaye de faire arriver ce qui lance habituellement kwrited (éventuellement essaye de killer kwrited aussi).
  Sinon, pour tester plus vite, tu peux directement faire "cat /dev/pts/0" dans un shell :). D'ailleurs ce fichier est un fichier spécial, un "character device" (je crois qu'on ne peut pas seeker (autrement dit te déplacer dans le fichier, tout comme les fichiers "FIFO"s) dessus).

  • [^] # Re: une raison ?

    Posté par Namlook le 07 mai 2006 à 22:58. Évalué à 1.

    

    J'ai déjà testé le "cat /dev/pts/0" et ça ne fonctionne pas... mais je n'avais pas killé kwrited avant.
    
    En fait, j'aurais bien lu les sources de kwrited pour voir comme il fait (et ce qui à été fait peut être refait) mais le problème, c'est que les sources de kwrited sont inclues directement dans le tronc commun de KDE (kdelib ? kdebase ?) donc assez inaccessible...
    
    D'autres idée ? Est-ce que quelqu'un sait comment kwrited s'y prend ?
    Merci !

    • [^] # Re: une raison ?

      Posté par z a le 08 mai 2006 à 00:01. Évalué à 1.

      

      tu n'as pas lu complétement mon message ? il faudrait peut-être que tu attendes que quelque chose écrive dans ce fichier (qui est un fichier spécial), essaye de refaire ce qui affiche des messages dans kwrited.
      Comme c'est un fichier qui n'est pas sur le disque, mais un fichier "virtuel" créé par le kernel (je n'ai aucune idée de tes connaissances à propos des systèmes de fichiers, connait tu les fichiers de type "FIFO" par exemple (faisables avec la commande "mkfifo")), le fichier ne contient pas de données lisibles immédiatement comme tu aurais l'habitude si tu lisais un fichier "normal".
      
      De plus (là je m'aventure peut-être trop loin et je dis des conneries), comme c'est un fichier "character device" et que tu ne peux pas seeker dessus, il est aussi possible que les données ne puissent être lues qu'une fois (là encore contrairement à un fichier "régulier"), et qu'il faut donc que seul ton prog le lise, et que donc il ne faut pas que kwrited ait la possibilité de le lire.
      
      [désolé si le contenu du message est lourd, dis-moi, en fait j'ai essayé de te raconter plein de trucs pour te donner des pistes ;) ]

      • [^] # Re: une raison ?

        Posté par Namlook le 08 mai 2006 à 12:27. Évalué à 1.

        

        Sisi j'avais bien tout lu et évidemment, pendant le "cat /dev/pts/0" j'avais envoyé des donnés dedans (par l'intermédiaire de "echo "coucou" >> /dev/pts/0". C'était tellement évident que j'en ai pas parlé dans mon message précédent.
        
        Je suis tout a fait d'accord avec toi. On ne peut pas "seeker" un fichier FIFO et il faut attendre qu'il y ait un flux pour pouvoir le récupérer. Ou du moins, il faut qu'il y ait un processus qui reste actif pour pouvoir "écouter" le fichier.
        
        Toute la question est : comment faire ? Comment s'y prend kwrited pour écouter ce fichier ?
        
        J'ai bien sur regardé sur mon ami google mais je n'ai trouvé aucune piste. Même koders.com ne me donne pas les sources de kwrited...
        
        @ Vot' bon coeur m'sieurs-dames :-)

        • [^] # Re: une raison ?

          Posté par z a le 08 mai 2006 à 13:38. Évalué à 2.

          

          j'ai trouvé ça : http://websvn.kde.org/branches/KDE/3.5/kdebase/konsole/konso(...)

• # Capitaine ! Une solution à l'horizon !

  Posté par Namlook le 08 mai 2006 à 13:11. Évalué à 1.

  

  Je pense entrevoir une solution à mon problème. Mon idée est de redirigé tout ce qui sort de /dev/pts/1 vers un simple fichier texte via dup2. Ensuite, il suffit de lire le fichier texte à intervalle de temps régulier :-)
  
  Ca serait faisable ?

Suivre le flux des commentaires

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