Voilà j'ai un petit script dont le but est de faire de la recherche de
motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne
correctement par contre sous linux, cela bloque sur certains fichiers comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui au
regard du fichier n'aura jamais lieu.
Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;}
if (-d $fichier) {return;}
open FIC, "<$fichier";
Quel est le problème ? Existe t il un moyen de savoir si un fichier est
locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais
je n'ai rien trouvé pour tester si un fichier est locké), est il aussi
possible de définir un temps maximum d'attente pour l'ouverture d'un fichier
?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel Rodriguez
Arnaud wrote:
Bonjour à tous,
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent et que ma demande est mise en attente jusqu'à libération du blocage qui au regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;} if (-d $fichier) {return;} open FIC, "<$fichier";
Est-ce que tu as essaye
open( FIC, "<$fichier") or die "probleme sur open $fichier: $!"
AU moins ca te donnera exactement le probleme, plutot que tu essayes de le deviner.
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
Arnaud wrote:
Bonjour à tous,
Voilà j'ai un petit script dont le but est de faire de la recherche de
motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne
correctement par contre sous linux, cela bloque sur certains fichiers comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui au
regard du fichier n'aura jamais lieu.
Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;}
if (-d $fichier) {return;}
open FIC, "<$fichier";
Est-ce que tu as essaye
open( FIC, "<$fichier") or die "probleme sur open $fichier: $!"
AU moins ca te donnera exactement le probleme, plutot que tu essayes de
le deviner.
--
Michel Rodriguez
Perl & XML
http://www.xmltwig.com
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent et que ma demande est mise en attente jusqu'à libération du blocage qui au regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;} if (-d $fichier) {return;} open FIC, "<$fichier";
Est-ce que tu as essaye
open( FIC, "<$fichier") or die "probleme sur open $fichier: $!"
AU moins ca te donnera exactement le probleme, plutot que tu essayes de le deviner.
-- Michel Rodriguez Perl & XML http://www.xmltwig.com
root
On Fri, 05 Dec 2003 10:08:56 +0100, Arnaud wrote:
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent et que ma demande est mise en attente jusqu'à libération du blocage qui au regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;} if (-d $fichier) {return;} open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard » if( not -f $fichier ) { print "$fichier n'est pas un fichier standard !n"; return; } # teste si accessible en lecture if( not -r $fichier ) { print "Lecture de $fichier impossible"; return; } # on ouvre et on regarde s'il n'y a pas d'erreur... if( not open FIC, "<", $fichier ) { print "Erreur ouverture de $fichier : $!n"; return; }
Quel est le problème ? Existe t il un moyen de savoir si un fichier est locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais je n'ai rien trouvé pour tester si un fichier est locké), est il aussi possible de définir un temps maximum d'attente pour l'ouverture d'un fichier ?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard » et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé au clavier, de plus une opération de lecture sur ce fichier est bloquante, et ne retournera que lorsqu'il y aura des données tapé sur le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage. Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une ouverture et une lecture de /dev/dsp permet de demander au kernel de commencer l'échantillonnage sur la carte son et de transmettre les données échantillonnés lorsque tu feras un read() sur ce descripteur de fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe' (man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des données écrites par quelqu'un d'autres sur ce même pipe.
On Fri, 05 Dec 2003 10:08:56 +0100, Arnaud wrote:
Voilà j'ai un petit script dont le but est de faire de la recherche de
motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne
correctement par contre sous linux, cela bloque sur certains fichiers comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui au
regard du fichier n'aura jamais lieu.
Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;}
if (-d $fichier) {return;}
open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des
fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le
kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un
fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard »
if( not -f $fichier ) {
print "$fichier n'est pas un fichier standard !n";
return;
}
# teste si accessible en lecture
if( not -r $fichier ) {
print "Lecture de $fichier impossible";
return;
}
# on ouvre et on regarde s'il n'y a pas d'erreur...
if( not open FIC, "<", $fichier ) {
print "Erreur ouverture de $fichier : $!n";
return;
}
Quel est le problème ? Existe t il un moyen de savoir si un fichier est
locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais
je n'ai rien trouvé pour tester si un fichier est locké), est il aussi
possible de définir un temps maximum d'attente pour l'ouverture d'un fichier
?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard »
et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce
qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé
au clavier, de plus une opération de lecture sur ce fichier est
bloquante, et ne retournera que lorsqu'il y aura des données tapé sur
le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage.
Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une
ouverture et une lecture de /dev/dsp permet de demander au kernel de
commencer l'échantillonnage sur la carte son et de transmettre les
données échantillonnés lorsque tu feras un read() sur ce descripteur de
fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers
supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique
et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe'
(man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en
lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des
données écrites par quelqu'un d'autres sur ce même pipe.
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent et que ma demande est mise en attente jusqu'à libération du blocage qui au regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;} if (-d $fichier) {return;} open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard » if( not -f $fichier ) { print "$fichier n'est pas un fichier standard !n"; return; } # teste si accessible en lecture if( not -r $fichier ) { print "Lecture de $fichier impossible"; return; } # on ouvre et on regarde s'il n'y a pas d'erreur... if( not open FIC, "<", $fichier ) { print "Erreur ouverture de $fichier : $!n"; return; }
Quel est le problème ? Existe t il un moyen de savoir si un fichier est locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais je n'ai rien trouvé pour tester si un fichier est locké), est il aussi possible de définir un temps maximum d'attente pour l'ouverture d'un fichier ?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard » et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé au clavier, de plus une opération de lecture sur ce fichier est bloquante, et ne retournera que lorsqu'il y aura des données tapé sur le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage. Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une ouverture et une lecture de /dev/dsp permet de demander au kernel de commencer l'échantillonnage sur la carte son et de transmettre les données échantillonnés lorsque tu feras un read() sur ce descripteur de fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe' (man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des données écrites par quelqu'un d'autres sur ce même pipe.
Arnaud
Merci beaucoup ! Ca marche tip top !!!
Arnaud.
"root" a écrit dans le message de news:
On Fri, 05 Dec 2003 10:08:56 +0100, Arnaud wrote:
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui au
regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;}
if (-d $fichier) {return;} open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard » if( not -f $fichier ) { print "$fichier n'est pas un fichier standard !n"; return; } # teste si accessible en lecture if( not -r $fichier ) { print "Lecture de $fichier impossible"; return; } # on ouvre et on regarde s'il n'y a pas d'erreur... if( not open FIC, "<", $fichier ) { print "Erreur ouverture de $fichier : $!n"; return; }
Quel est le problème ? Existe t il un moyen de savoir si un fichier est locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais
je n'ai rien trouvé pour tester si un fichier est locké), est il aussi possible de définir un temps maximum d'attente pour l'ouverture d'un fichier
?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard » et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé au clavier, de plus une opération de lecture sur ce fichier est bloquante, et ne retournera que lorsqu'il y aura des données tapé sur le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage. Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une ouverture et une lecture de /dev/dsp permet de demander au kernel de commencer l'échantillonnage sur la carte son et de transmettre les données échantillonnés lorsque tu feras un read() sur ce descripteur de fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe' (man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des données écrites par quelqu'un d'autres sur ce même pipe.
Merci beaucoup !
Ca marche tip top !!!
Arnaud.
"root" <root@localhost.localdomain> a écrit dans le message de
news:pan.2003.12.05.11.29.31.5657@localhost.localdomain...
On Fri, 05 Dec 2003 10:08:56 +0100, Arnaud wrote:
Voilà j'ai un petit script dont le but est de faire de la recherche de
motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne
correctement par contre sous linux, cela bloque sur certains fichiers
comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès
concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui
au
regard du fichier n'aura jamais lieu.
Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable
en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible";
return;}
if (-d $fichier) {return;}
open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des
fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le
kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un
fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard »
if( not -f $fichier ) {
print "$fichier n'est pas un fichier standard !n";
return;
}
# teste si accessible en lecture
if( not -r $fichier ) {
print "Lecture de $fichier impossible";
return;
}
# on ouvre et on regarde s'il n'y a pas d'erreur...
if( not open FIC, "<", $fichier ) {
print "Erreur ouverture de $fichier : $!n";
return;
}
Quel est le problème ? Existe t il un moyen de savoir si un fichier est
locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier
mais
je n'ai rien trouvé pour tester si un fichier est locké), est il aussi
possible de définir un temps maximum d'attente pour l'ouverture d'un
fichier
?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard »
et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce
qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé
au clavier, de plus une opération de lecture sur ce fichier est
bloquante, et ne retournera que lorsqu'il y aura des données tapé sur
le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage.
Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une
ouverture et une lecture de /dev/dsp permet de demander au kernel de
commencer l'échantillonnage sur la carte son et de transmettre les
données échantillonnés lorsque tu feras un read() sur ce descripteur de
fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers
supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique
et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe'
(man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en
lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des
données écrites par quelqu'un d'autres sur ce même pipe.
Voilà j'ai un petit script dont le but est de faire de la recherche de motifs ds les fichiers. Sous windows XP & 2000 pro cela fonctionne correctement par contre sous linux, cela bloque sur certains fichiers comme
les /dev-console ... Je pense qu'il s'agit d'un problème d'accès concurrent
et que ma demande est mise en attente jusqu'à libération du blocage qui au
regard du fichier n'aura jamais lieu. Ce que je ne comprends pas c'est que je teste si le fichier est ouvrable en
lecture avant de l'ouvrir :
if (not (-r $fichier)) {warn "Lecture de $fichier impossible"; return;}
if (-d $fichier) {return;} open FIC, "<$fichier";
Le problème est que les fichiers de /dev ne sont pas vraiment des fichiers... ce sont des fichiers qui permettent de « dialoguer » avec le kernel/drivers du kernel.
Dans ton cas il faut simplement tester si le fichier est « vraiment un fichier » avec le test `-f' avant d'ouvrir ton fichier :
# teste si le fichier existe et est un fichier « standard » if( not -f $fichier ) { print "$fichier n'est pas un fichier standard !n"; return; } # teste si accessible en lecture if( not -r $fichier ) { print "Lecture de $fichier impossible"; return; } # on ouvre et on regarde s'il n'y a pas d'erreur... if( not open FIC, "<", $fichier ) { print "Erreur ouverture de $fichier : $!n"; return; }
Quel est le problème ? Existe t il un moyen de savoir si un fichier est locké (j'ai bien lu la doc sur flock qui dit comment locker un fichier mais
je n'ai rien trouvé pour tester si un fichier est locké), est il aussi possible de définir un temps maximum d'attente pour l'ouverture d'un fichier
?
Ton blocage n'a rien a voir avec les « lock » (flock, etc.).
C'est juste que ce genre de fichier n'est pas un fichier « standard » et n'a, la plupart du temps, pas de fin.
En gros, lorsqu'une application ouvre /dev/console, elle peut y lire ce qui est tapé au clavier, en quelque sorte elle capture ce qui est tapé au clavier, de plus une opération de lecture sur ce fichier est bloquante, et ne retournera que lorsqu'il y aura des données tapé sur le clavier, d'ou le fait qu'il n'y a pas de fin, d'ou le blocage. Il y d'autres fichiers dans ce genre, comme /dev/dsp pour le son. Une ouverture et une lecture de /dev/dsp permet de demander au kernel de commencer l'échantillonnage sur la carte son et de transmettre les données échantillonnés lorsque tu feras un read() sur ce descripteur de fichier. Idem pour l'écriture et donc jouer un son. Ces fichiers supportent en plus les ioctl (man ioctl) pour paramétrer le périphérique et par exemple changer la fréquence d'échantillonnage de la carte son.
Sans le test `-f' tu peux aussi tomber sur le problème des `pipe' (man mkfifo) qui sont des tuyaux bloquants. Une fois qu'il sont ouvert en lecture, une opération de lecture sera bloqué jusqu'à ce qu'il y ait des données écrites par quelqu'un d'autres sur ce même pipe.
