Souvenez vous… nous vous avions laissés il y a au moins deux minutes avec un script BASH qui générait un tableau très simple.
Ca a certes fait avancer un peu notre schmilblick, mais le plus gros reste à faire. Surtout à écrire.
Pour chaque lien, il va falloir rajouter trois cases :
- le lien vers la page aspirée en local (oui, nous sommes des pirates sans scrupules, sans vergogne et sans guinaires. Yohoho, et une bouteille de rhum!)
- le lien vers la version texte brut de la page locale (parce qu’en plus on mutile les pages web ! Bwahaha !)
- le lien vers la concordance, c’est à dire le mot dans son contexte dans la page aspirée.
Pour ce faire, trois commandes Unix vont nous être utiles :
- WGET, sous la forme “wget -O <page à aspirer> <destination>
- LYNX, qui est en fait un navigateur web sous-doté en capacités graphiques, mais qui a la capacité de réduire uen page web à portion congrue. Sauf qu’il ne le fait pas dans un fichier, du coup il faudra générer un flux. Pour faire clair, la commande sera : “lynx -dump <URL page locale> >> fichier_destination”
- EGREP, qui permet d’isoler les lignes contenant un mot bien précis dans un fichier text. On l’utilisera sous la forme : “egrep -i [char] <adresse de la page en mode texte>”.
Après une version fonctionnelle mais peu subtile en bash bourrin, nous découvrîmes quelques structures et possibilités de BASH qui allaient donner à ce script une classe folle. Mais avant tout cela, nous réorganisâmes nos fichiers contenant des URLs d’une nouvelle façon. Au lieu d’un fichier par langue (on aurait oublié de vous dire qu’on travaille dans le but de vérifier la traduction d’un terme polysémique via une table de concordances ? Bon, ben, c’est fait…), nous aurons un fichier par sens, dont le contenu sera rangé de la sorte :
<SENS>
FR
<liste d’urls en français>
EN
<liste d’urls en anglais>
Voyons maintenant ce que cela nous apporte.
Tout d’abord, BASH permet d’exploiter des procédures (aka “fonctions”), ce qui permet de soulager le programmeur qui voudrait relire son script, ou pire : le modifier (a-t-on idée, aussi !). Une fonction BASH s’écrira sous la forme :
- fonction()
{<jeu d’instructions>
}
Et elle sera appelée directement par son nom : fonction, sans plus de fioritures.
Ensuite, la structure case permet de remplacer avantageusement une structure du genre if then elsif elsif else, bref, un choix multiple plein d’indentations qui finissent par mettre le code hors de l’écran. Un exemple (et là on avait pas encore tout le code) :
Case, par contre, ça donne un truc du genre :
- case variable in
cas1 ) <série d’instructions> ;;
cas2 ) <série d’instructions> ;;
…
casN) <série d’instructions> ;;
esac
( avec cas1, cas2, casN des chaînes de caractères, ou des valeurs suivant l’utilisation. Ici, des chaînes de caractères).
Du coup, on a désormais un script BASH écrit avec des appels de fonctions qui n’utilisent que des variables globales (ça facilite la vie) et une structure principale qui est une boucle imbriquée avec gestion de cas. Et ça donne, en gros, ça :
projet-bash-final.jpg
Les contextes sont encore à implémenter.
Mais il y a pire ! Il s’est soudain avéré que l’attribut substr de la commande expr n’était pas implémenté sur certaines versions de BASH. Zut et flûte ! (oui, on se censure un peu, là…)
Du coup, il nous a fallu trouver une autre solution.
parce que reprogrammer substr comme si de rien n’était, c’est franchement too much.
Et donc, nous nous sommes documentés. Et nous avons découvert…
Suspense.
Suspense..
Suspense…
nous avons découvert que la fonction substr était nativement implémentée dans le langage … PERL.
et comme nous sommes capables de raisonner et tirer des conclusions, nous décidâmes de réécrire le programme en PERL. Logique.
Mais ceci est une autre histoire…
