Master 1 Plurital 2012
November 27 2012
Comme nous avons vu pendant la dernière séance, nous visons d’extraire le contenu textuel des pages aspirées. Les étapes qui suivent nécessitent du travail sur les pages que nous avons aspirées en utilisant "wget" ou "curl". Donc, la première étape qu’il faudra faire est de vérifier si l’aspiration de la page a réussi. S’il y a eu une erreur, ça ne vaut pas la peine de continuer à travailler sur la page.
En dessous est une des URLS britanniques, qui existe toujours et s'affiche bien à l'écran. En exécutant les scripts précénts, cette page est bien aspirée.
Pour comparer l'aspiration de cette page (qui est réussie) à une aspiration qui ne devrait pas réussir, j'effectue un peu de sabotage de l'URL en changeant d'un caractère son nom (de 1999 à 1989). Cette nouvelle page n'existe pas - comme indiqué par le titre de la page, où s'affiche le message d'erreur - 404 Page not found.
Comment pouvons-nous savoir si notres pages ont été bien aspirées?
La commande "curl" ou "wget" renvoie une variable qui contient son code retour – une indication que la commande a bien marché ou non. Nous pouvons récupérer la valeur de cette variable en utilisant $? - une variable spéciale du shell qui renvoie le code retour de la dernière commande exécutée (dans notre cas la commande curl).
Si la commande réussit, le code retour sera 0. En effet, chaque faute est désignée par un numéro spécifique – un numéro autre que 0. Alors nous pouvons repérer s’il y a eu une erreur dans la commande, comme suit :
curl http://www.thesootyshow.com
retourcurl = $?
#si le code retour de curl n’est pas égal à zéro – s’il y a eu un message d’erreur ; alors
if [ retourcurl -ne 0 ] ; then
…
ou également (pour commencer par les sites qui ont été aspirées)
if [ retourcurl –eq 0 ] ; then
…
N.B:
Pour tester le code retour de plusieurs sites, j'ai utilisé les commandes "curl" et "wget" sur des URLs légèrement modifiées. Le résultat est plusieurs codes différents, selon l'erreur produit. La première URL a bien été aspirée (avec un code retour de 0), mais en modifiant l'URL, nous voyons des codes retour différent de 0, indiquant une erreur de la commande.
Le code retour semble bien nous indiquer le résultat de l'aspiration. Parmi les exemples ci-dessus, curl/wget a renvoyé un 0 (réussite) seulement pour l'URL qui existait. Les autres renvoyait un code autre que 0.
Cependant, si nous essayons de démontrer la même chose avec les deux sites de "The Guardian", voilà ce qui se passe :
Pourtant, nous avons bien vu au début que la deuxième page n'existe pas. Alors, pourquoi notre code retour de curl est-il 0 ?
Le problème est lié au fait que le code retour indique si la commande "curl" a bien marché ou pas. Il n'est pas une indication que nous avons aspiré ce que nous voulions aspirer comme page. Si la commande reçoit une réponse, il peut considérer qu’elle a bien fonctionné. Pourtant, quelquefois elle reçoit de mauvaises réponses – des messages d’erreur qui, par exemple, indique que la page n’a pas été trouvée. C'est ce qui se passe avec notre deuxième lien. Curl reçoit un message de réponse, et considère, donc, que la commande a marché. A l'écran j'ai un site html - une réponse de curl - mais non pas le contenu que je voulais obtenir. Le contenu de la réponse est donc important !
Une autre solution pour vérifier si l'aspiration a réussi ?
Heuresement, "curl" a beaucoup d’options et il existe une option –w (ou –write-out) qui renvoie certaines informations sur l’exécution de la commande.
Il est possible de spécifier quelles variables nous voulons voir en les entourant de %{} :
--write-out %{http_code}
Cela veut dire que le code retour de la requête http sera renvoyé à l’écran.
D’autres options permettent de nettoyer la réponse un peu – au lieu d’avoir le code retour ET la page aspirée par "curl".
-s (ou –silent) permet de rendre le processus de curl « silencieux »
- o /dev/null permet de se débarrasser du texte qui est renvoyé par "curl" (c’est-à-dire la page aspirée). Ce texte sera renvoyé à /dev/null où il sera détruit immédiatement. C’est un fichier poubelle – un "trou noir". Alors ceci nous permet de récupérer seulement le retour code http de "curl", qu’on peut ensuite stocker dans une variable :
r = $(curl –o /dev/null –silent –write-out %{http_code} http://www.thesootyshow.com)
echo $r
Et donc cette fois-ci, il y a une distinction entre les deux pages (entre celle qui a été bien aspirée - au code retour 200 et celle qui n'a pas été correctement aspirée - au code retour 404) :
Cette fois-ci le code retour qui indique que tout s'est bien passé n’est pas 0 mais 200.
Nous pouvons créer une condition comme avant, afin de traiter seulement les pages qui ont été correctement aspirées :
if [ r –eq 200 ] ; then
…
ou les pages pour laquelle le code retour http indique qu’il y a eu une erreur :
if [ r -ne 200 ] ; then
…
Dans notre cas, nous ne pouvons pas continuer à travailler avec une page qui n'est pas bien aspirée. Il faudrait donc indiquer l'erreur de l'aspiration et abandonner la page, les étapes suivantes étant effectuées exclusivement sur les pages qui sont bien aspirées.
Pour vérifier que toutes les pages ont été bien aspirées, quelques conditions ont été incluses dans notre script principal, pour afficher dans le tableau le code retour curl et le code retour http (afin de les comparer). Un peu de formatage du tableau nous permet de voir les erreurs plus clairement - et quels erreurs !
Nous pouvons remarquer d'abord que le code retour http signale plus d'erreurs le code curl, comme prévu. Si nous regardons les liens vers les pages aspirées, nous voyons qu'il y avait bien des problèmes avec l'aspiration de la plupart de ces pages. Je dis plupart, car maintenant il y a le petit souci qu'il existe des pages bien aspirées qui ont renvoyé un code d'erreur.
Parmi les autres réponse il y a :