pluriTAL – BLOG Master pluriTAL [ParisX, ParisIII, INALCO]

AB-CJ : dernier problème avec wget.

Posted in Projet 2006-2007 by pluritaluser on 18 décembre 2006

Bonsoir à tous,

vous devez sans doute avoir fini votre programme, même votre rapport, et puis et puis il y a un petit problème. Lorsque vous regardez votre tableau résultat vous vous apercevez qu’il y a bien une URL pointant vers un site en ligne bien visible avec votre navigateur mais que les pages aspirées, lynxées et contextualisées sont vides, des cellules blanches, des liens pointant sur des pages blanches.

C’était notre cas à Arianna et Moi, et nous étions vraiment très perturbés, surtout que nous pouvions nous vanter d’avoir un programme robuste croyez-t-on. Nous étions sûr de vérifier que le téléchargement de wget avait bien fonctionné avant d’exécuter la suite des traitements. Nous avions fait une erreur que voici :

Pour tester la réussite de wget nous faisions :

wget …. -O $ficDestAsp url

if [ -f $ficDestAsp ]

then

lynx ….

fi

Nous pensions que tester l’existence du fichier avec -f était suffisant mais il n’en est rien, car wget même s’il commet une erreur de téléchargement, va créér ce fichier mais il sera vide.

La véritable solution consiste à regarder le code de sortie du programme wget qui est visible dans la variable interne du shell $? qui vaut 0 (zéro) en cas de succès et autre en cas d’erreur.

Voici la solution :

wget … -O $ficDestAsp url

err=$? ## Il vaut mieux la sauvegarder dans une autre variable et tester cette variable car $? est très souvent

##modifiée

# Le test sur le fichier est optionnel, mais j’aime l’élégance de la ligne suivante.

if [ -f $ficDestAsp ] && [ $err -eq ‘0’ ]
then

lynx, ……
else

#loggue url recalcitrante

fi

Parmi les causes possibles nous avions identifiés une erreur qui nous paraissait improbable mais qui nous est arrivée, c’est que nous utilisions dans wget les options password et user, ainsi certains sites où leurs pages ne demandent pas de mot de passe, en leur fournissant un mot de passe, l’accès était refusé à wget, nous obtenions une page forbidden access mais heureusement pas stocké dans le fichier html, celui restant vide mais existant. Dans un tel cas wget renvoie 1, super.

Les autes problèmes concernent souvent les user-agent, les sites webs attendent internet explorer ou mozilla/netscape comme navigateur qui est déclaré dans la variable user-agent, s’il voit wget il refuse de servir la page, dans ce cas on obtient aussi un 1, ce cas demande plus de vérification.

Avec ce test, nous n’avons plus de page blanche dans notre tableau résultat, il est enfin tout beau.

Arianna et Christian.

Publicités

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :