lecture fichier en continu

Le
Grobill
Bonjour.

Le but est de faire un log-viewer (linux/Kdevelop).
Quel est a votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ?
Y'a-t-il une solution meilleure qu'ouvrir les fichiers toutes les x
secondes et recuperer les nouvelles entrées ?

Merci d'avance.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Arnaud Meurgues
Le #737746
Grobill wrote:

Le but est de faire un log-viewer (linux/Kdevelop).
Quel est a votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ?
Y'a-t-il une solution meilleure qu'ouvrir les fichiers toutes les x
secondes et recuperer les nouvelles entrées ?


Sur certain système, il est possible d'être notifié quand un fichier
change. C'est peut-être possible sous linux. Il faudrait demander dans
un groupe idoine.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Christophe de VIENNE
Le #737740
Grobill wrote:
Bonjour.

Le but est de faire un log-viewer (linux/Kdevelop).
Quel est a votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ?
Y'a-t-il une solution meilleure qu'ouvrir les fichiers toutes les x
secondes et recuperer les nouvelles entrées ?


Personnellement je regarderais du côté de la commange tail. Soit
regarder comment c'est fait, soit carrément l'utiliser et lire sa sortie
standard.
Mais c'est plutot lié à l'OS comme question, il vaudrait mieux la poser
sur un groupe approprié.

A+

Christophe

Grobill
Le #737738
Merci, je viens de poster "in english" sur un comp.linux.truc-chose.
Grobill
Le #715992
Pour ceux que ca pourrait interesser j'ai trouvé une solution en regardant
mieux la STL.
ios fournit la classe filebuf qui permet d'avoir un buffer en lecture (et
ecriture aussi) d'un fichier ouvert. De cette maniere la lecture est
continue et transparente et on ne check que le nombre de char available
dans le buffer qd on le desire.

Il y a bien des wraper qui permettent d'etre informés d'une modification
dans un fichier, mais ca a l'air bcp plus gourmand en ressources pour le
meme effet.


Grobill news::

Bonjour.

Le but est de faire un log-viewer (linux/Kdevelop).
Quel est a votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ?
Y'a-t-il une solution meilleure qu'ouvrir les fichiers toutes les x
secondes et recuperer les nouvelles entrées ?

Merci d'avance.



kanze
Le #715775
Arnaud Meurgues news:
Grobill wrote:

Le but est de faire un log-viewer (linux/Kdevelop). Quel est a
votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ? Y'a-t-il une
solution meilleure qu'ouvrir les fichiers toutes les x secondes et
recuperer les nouvelles entrées ?


Sur certain système, il est possible d'être notifié quand un fichier
change. C'est peut-être possible sous linux. Il faudrait demander dans
un groupe idoine.


Ça dépend en effet du système. Autant que je sache, il n'y a pas de
telle fonctionnalité sous Linux. En général, on garde le fichier ouvert,
et on ressaie d'y lire de temps en temps.

Le faire avec un flux standard, c'est moins évident. D'abord,
évidemment, une fois apparues, les erreurs et les fins de fichier dans
un flux reste. Il faut appeler clear() pour les anuller. Mais même en
appelant clear(), ce n'est pas sûr qu'il ne soit pas mémorisé dans le
filebuf même. (Je crois que c'est le cas avec g++, par exemple.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Matthieu Moy
Le #715774
writes:

Arnaud Meurgues news:
Grobill wrote:

Le but est de faire un log-viewer (linux/Kdevelop). Quel est a
votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ? Y'a-t-il une
solution meilleure qu'ouvrir les fichiers toutes les x secondes et
recuperer les nouvelles entrées ?


Sur certain système, il est possible d'être notifié quand un fichier
change. C'est peut-être possible sous linux. Il faudrait demander dans
un groupe idoine.


Ça dépend en effet du système. Autant que je sache, il n'y a pas de
telle fonctionnalité sous Linux. En général, on garde le fichier ouvert,
et on ressaie d'y lire de temps en temps.


Je crois que c'est ce que fait "tail -f", il faudrait aller voir les
sources de tail, qui ne doivent pas être trop compliquées ...

--
Matthieu



kanze
Le #715773
Grobill news:
Pour ceux que ca pourrait interesser j'ai trouvé une solution en
regardant mieux la STL. ios fournit la classe filebuf qui permet
d'avoir un buffer en lecture (et ecriture aussi) d'un fichier
ouvert. De cette maniere la lecture est continue et transparente et on
ne check que le nombre de char available dans le buffer qd on le
desire.


Et comment fait-on pour voir s'il y a des caractères disponibles ? Je
crois que la sémantique garantie de in_avail() va te decevoir, si c'est
sur elle que tu comptais. (Mais il se peut que ton implémentation en
garantisse plus. Je ne sais rien en ce qui concerne g++ ici.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Grobill
Le #715548
Quel devrait etre le probleme ?
J'ai testé avec in_avail en effet, mais ca a l'air de fonctionner...
J'ai juste ecrit un petit test a la va-vite pour verifier justement :

using namespace std;

int main(int argc, char *argv[]) {
int n = 0;
int nblus = 0;
ios::pos_type lastpos;
std::streamsize nbavail, nbgot;
ifstream pipofile;
char cline[4096];

filebuf *pipobuf;
pipobuf = pipofile.rdbuf();
pipobuf->open("/var/log/messages", ios::in | ios::ate);

while(n==0) {
nbavail = pipobuf->in_avail();
cout << nbavail << endl;
if(nbavail > 30) {
nbgot = pipobuf->sgetn(cline, nbavail);
cline[nbgot-2] = '';
cout << cline << endl;
}
sleep(2);
}

pipobuf->close();

return EXIT_SUCCESS;
}


wrote in
news::

Grobill news:
Pour ceux que ca pourrait interesser j'ai trouvé une solution en
regardant mieux la STL. ios fournit la classe filebuf qui permet
d'avoir un buffer en lecture (et ecriture aussi) d'un fichier
ouvert. De cette maniere la lecture est continue et transparente et on
ne check que le nombre de char available dans le buffer qd on le
desire.


Et comment fait-on pour voir s'il y a des caractères disponibles ? Je
crois que la sémantique garantie de in_avail() va te decevoir, si c'est
sur elle que tu comptais. (Mais il se peut que ton implémentation en
garantisse plus. Je ne sais rien en ce qui concerne g++ ici.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34




kanze
Le #716179
Grobill news:
Quel devrait etre le probleme ?

J'ai testé avec in_avail en effet, mais ca a l'air de fonctionner...
J'ai juste ecrit un petit test a la va-vite pour verifier justement :

using namespace std;

int main(int argc, char *argv[]) {
int n = 0;
int nblus = 0;
ios::pos_type lastpos;
std::streamsize nbavail, nbgot;
ifstream pipofile;
char cline[4096];

filebuf *pipobuf;
pipobuf = pipofile.rdbuf();
pipobuf->open("/var/log/messages", ios::in | ios::ate);

while(n==0) {
nbavail = pipobuf->in_avail();
cout << nbavail << endl;
if(nbavail > 30) {
nbgot = pipobuf->sgetn(cline, nbavail);
cline[nbgot-2] = '';
cout << cline << endl;
}
sleep(2);
}

pipobuf->close();

return EXIT_SUCCESS;
}


Simplement que in_avail() ne garantit qu'un minimum, mais pas tout.
C-à-d que si in_avail() renvoie « n », tu es garanti que tu peux lire n
caractères sans bloquer. Le fichier contient donc au moins n caractères.
Au moins, mais il peut bien en contenir plus. Une implémentation légale
pourrait bien n'en renvoyer que le nombre de caractères dans le buffer
(et donc, toujours 0 tant que tu n'a pas appelé sgetc au moins une
fois).

En fait, à part sous Unix et ses semblables, c'est difficile à savoir
comment il pourrait en faire mieux. (Techniquement, d'ailleurs, même
sous Unix... Supposons que in_avail() renvoie 100000, parce que ça
correspond à la taille du fichier. Mais que dans le moment entre l'appel
à in_avail() et la lecture du fichier, un autre processus vient appeler
truncate.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze
Le #716178
Matthieu Moy news:
writes:

Arnaud Meurgues news:
Grobill wrote:

Le but est de faire un log-viewer (linux/Kdevelop). Quel est a
votre avis le meilleur moyen pour recuperer en temps-réel (ou
presque) les nouvelles lignes des fichiers concernés ? Y'a-t-il
une solution meilleure qu'ouvrir les fichiers toutes les x
secondes et recuperer les nouvelles entrées ?


Sur certain système, il est possible d'être notifié quand un
fichier change. C'est peut-être possible sous linux. Il faudrait
demander dans un groupe idoine.


Ça dépend en effet du système. Autant que je sache, il n'y a pas de
telle fonctionnalité sous Linux. En général, on garde le fichier
ouvert, et on ressaie d'y lire de temps en temps.


Je crois que c'est ce que fait "tail -f", il faudrait aller voir les
sources de tail, qui ne doivent pas être trop compliquées ...


C'est en tout cas la solution décrite dans « The Unix Programming
Environement », de Kernighan et Pike. Sorti en 1978 -- ce n'est pas
vraiment une idée nouvelle.

Mais pour le faire, et pour que ça marche (au moins de façon garantie),
il faut utiliser les requêtes Posix, et non l'interface de flux de C++.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34




Publicité
Poster une réponse
Anonyme