problème script cgi: Time::Local renvoie un tas d'erreurs
Le
gvdmoort
Bonjour à tous,
J'ai un script qui fait appel à Time::Local pour convertir un temps au
format YYYYMMDD en epoch et permettre des comparaisons entre des dates.
sub get_time {
$_[0]=~/(.)(..)(..)/;
$year = $1;
$month = $2;
$day = $3;
$date=timelocal(0,0,12,$day, $month-1, $year-1900);
# pour débugguer (voir le résultat plus loin) :
print STDERR "$year $month $day$date";
return $date;
}
Malheureusement, chaque appel à cette fonction entraîne l'envoi de
ces messages vers STDERR:
Use of uninitialized value in integer addition (+) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in integer multiplication (*) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in integer multiplication (*) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in pack at C:/perl/lib/Time/Local.pm line
67, <INDEX> line 393.
Use of uninitialized value in pack at C:/perl/lib/Time/Local.pm line
67, <INDEX> line 393.
Use of uninitialized value in integer addition (+) at
C:/perl/lib/Time/Local.pm line 67, <INDEX> line 393.
2006 04 26
1146046210
Comme la comparaison s'effectue sur quelques centaines de dates, ça
fait quelques milliers de lignes d'erreur à chaque fois.
Il semble que la sortie d'erreur standard soit redirigée vers la
sortie standard pour les scripts CGI, en tout cas, la page s'affiche en
entremêlant le code html normal et ces lignes d'erreur, et après un
temps désespérément long. J'ai tenté de rediriger les erreurs vers
un fichier :
open (STDERR,">errors.txt");
ce qui rend au script son temps d'exécution normal, mais il tourne
sur un serveur Windows, environnement auquel je ne connais rien, je le
confesse, et les visiteurs qui n'ont pas accès en écriture sur ce
répertoire ne peuvent créer ce fichier (on est dans l'intranet d'une
entreprise), et ça coince tout autant.
Quelqu'un a-t-il une idée de l'origine de ces erreurs, et si elles ne
peuvent être résolues, faute de mieux,
y aurait-il une grosse ficelle correspondant par exemple à une
redirection vers /dev/null pour en être quitte ?
Merci d'avance,
G.
J'ai un script qui fait appel à Time::Local pour convertir un temps au
format YYYYMMDD en epoch et permettre des comparaisons entre des dates.
sub get_time {
$_[0]=~/(.)(..)(..)/;
$year = $1;
$month = $2;
$day = $3;
$date=timelocal(0,0,12,$day, $month-1, $year-1900);
# pour débugguer (voir le résultat plus loin) :
print STDERR "$year $month $day$date";
return $date;
}
Malheureusement, chaque appel à cette fonction entraîne l'envoi de
ces messages vers STDERR:
Use of uninitialized value in integer addition (+) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in integer multiplication (*) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in integer multiplication (*) at
C:/perl/lib/Time/Local.pm line 76, <INDEX> line 393.
Use of uninitialized value in pack at C:/perl/lib/Time/Local.pm line
67, <INDEX> line 393.
Use of uninitialized value in pack at C:/perl/lib/Time/Local.pm line
67, <INDEX> line 393.
Use of uninitialized value in integer addition (+) at
C:/perl/lib/Time/Local.pm line 67, <INDEX> line 393.
2006 04 26
1146046210
Comme la comparaison s'effectue sur quelques centaines de dates, ça
fait quelques milliers de lignes d'erreur à chaque fois.
Il semble que la sortie d'erreur standard soit redirigée vers la
sortie standard pour les scripts CGI, en tout cas, la page s'affiche en
entremêlant le code html normal et ces lignes d'erreur, et après un
temps désespérément long. J'ai tenté de rediriger les erreurs vers
un fichier :
open (STDERR,">errors.txt");
ce qui rend au script son temps d'exécution normal, mais il tourne
sur un serveur Windows, environnement auquel je ne connais rien, je le
confesse, et les visiteurs qui n'ont pas accès en écriture sur ce
répertoire ne peuvent créer ce fichier (on est dans l'intranet d'une
entreprise), et ça coince tout autant.
Quelqu'un a-t-il une idée de l'origine de ces erreurs, et si elles ne
peuvent être résolues, faute de mieux,
y aurait-il une grosse ficelle correspondant par exemple à une
redirection vers /dev/null pour en être quitte ?
Merci d'avance,
G.
Poser une question
écrivait (wrote):
Rien ne vous garantit que l'expression régulière/rationnelle a été
reconnue ! Et si ce n'est pas le cas, $1, $2 et $3 peuvent contenir la
valuer 'undef'. Donc :
if ($_[0] =~ m/(d{4})(d{2})(d{2})/) {
$year = $1;
$month = $2;
$day = $3;
# ... et la suite ...
} else {
# ?? Il n'y avait pas de date dans $_[0]
}
Pour le problème de 'STDERR', il faut voir le configuration de serveur
Web et savoir comment il interagit avec un script CGI...
--
Paul Gaborit - Perl en français -
gérer l'expression régulière/rationnelle, mais dans ce cas
précis, c'est bien pour vérifier ça que j'ai intercalé la ligne de
débuggage
print STDERR "$year $month $dayn$daten";
et il s'avère que l'expression a été reconnue dans TOUS les cas mais
que les erreurs apparaissent cependant.
Merci quand même
G.
Les messages d'erreur précédemment cités disparaissent totalement
lorsque j'utilise l'heure gmt au lieu de l'heure locale:
$date=timegm(0,0,12,$day, $month-1, $year-1900);
Faudrait-il spécifier le fuseau horaire pour pouvoir utiliser l'heure
locale ?
G.
Pour résoudre les problèmes liés aux messages d'erreur, comment
faire pour rediriger STDERR vers STDOUT ?
Serait-il possible, avant de faire cette redirection, d'exécuter un
traitement sur ces chaînes (reformattage via regexp par ex.)
Merci d'avance,
G.
écrivait (wrote):
Ok. Je n'avais pas lu tout jusqu'au bout...
--
Paul Gaborit - Perl en français -