Projet Encadré : Barrage réalisé par AB & CJ

Réalisation : mode de travail

La phase de réalisation du projet s'est déroulée de façon atypique puisque le binôme Arianna et Christian s'est formé assez tardivement. Ce binôme avait une autre particularité étant donné que Christian avait déjà eu une expérience avec Bash, alors qu'Arianna était novice en programmation.

Par conséquent la réalisation du projet s'est dans un premier temps déroulée de manière parallèle. Il s'est ensuite avéré qu'une fusion des programmes était possible. Le programme initiale de Christian est disponible ici et celui d'Arianna là. Le programme fusionné est visible ici

Réalisation par CJ

L'écriture des programmes ici présentés n'a été possible que par la mise à disposition du Guide avancé des scripts bash. Il sera nommé Guide par la suite. Une autre page web intéressante sur les shells mais plutôt comme une introduction à leur utilisation est la page d'Isabelle Volant

Le traitement des entrées

Pour simplifier le travail, on a dans un premier temps créé une variable MOT initialisée à la valeur de la chaîne "barrage". On a simplifié cette tâche pour se concentrer sur un problème qui n'était pas spécifié mais tout de même intéressant, à savoir l'appel du programme depuis la ligne de commande avec des arguments. Si les arguments sont absents ou mal spécifiés alors le programme demande les valeurs du fichier et du titre du tableau de manière interactive. Voici le code correspondant :

# On teste si la ligne de commande ne contient pas le bon nombre
# d'argument. $NBPARAM est initialisé à 2 pour 2 arguments
if [ $# != $NBPARAM ]
then
    echo "Usage: $0 fichierUrl \"titre pour les usages\"";
    echo "Entre dans le mode interactif";
    #- Si le 1er paramètre n'est pas défini
    if [ -z $1 ]
	then
	echo "Tapez le nom de fichier contenant les URLs à traiter : ";
	read fichierUrl;
    else
	fichierUrl=$1;
    fi
 #- Idem 2ème paramètre avec titre remplaçant fichierUrl et $2 remplaçant $1
else
# La ligne contient le bon nombre d'arguments.
    fichierUrl=$1;
    titre=$2;
fi

Les variables du shell à retenir pour réaliser une lecture des paramètres à partir de la ligne de commande sont :

$# indique le nombre de paramètre passé sur la ligne de commande.
$0 est le nom du programme qui est appelé.
Les variables de $1 à $9 représente du premier au 9ème paramètre.
S'il y a plus de paramètre il faut utiliser une autre notation. Le 13ème paramètre est dans la variable ${13}, ...

Pour en savoir plus sur les paramètres on peut se référrer à cette page du Guide.

Le test de l'existence du fichier :

On doit maintenant réaliser en shell la partie de l'algorithme correspondant au test de l'existence du fichier. On a remarqué que dans la partie précédente on avait un test sur les variables, on va voir maintenant les test notamment sur les fichiers et les répertoires. Voici le code correspondant :

# Répertoires contenants les différents sous-répertoires, constituant 
# l'arborescence pré-définies du projet.
BREPASP="PAGES-ASPIREES"; BREPCONT="CONTEXTES"; BREPDUMP="DUMP-TEXT";
BREPURL="LISTES-URL"; BJOURNAL="JOURNAL";

# Liste contenant les répertoires principaux.
tabRep="$BREPASP $BREPCONT $BREPDUMP $BREPURL $BJOURNAL";

# Test de l'existence du fichier d'url dans le répertoire courant.
# ou dans le répertoire LISTES-URLS ainsi que de sa régularité.
if [ ! -f $fichierUrl ] && [ ! -f $BREPURL/$fichierUrl ]
then
    echo "Le fichier $fichierUrl n'existe ni dans le répertoire courant";
    echo " ni dans le répertoire $BREPURL ou n'est pas un fichier régulier";
    exit 1; #Code de sortie indiquant une erreur.
fi

On avait le choix entre l'option -e pour tester l'existence du fichier et l'option -f pour tester son existence et sa régularité. On a choisi -f car l'existence du fichier ne suffit pas, il faut en plus que ce soit un fichier régulier, pas une socket ni un répertoire par exemple. Le ! correspond à la négation du test.

On utilisera cette technique pour savoir si le téléchargement d'un fichier par wget à réussi.

Pour en savoir plus sur les tests de fichiers on peut se référrer à cette page du Guide.

L'arborescence : test et création

La prochaine étape de l'algorithme consiste à tester l'existence de l'arborescence du projet nécessaire au fonctionnement du programme, et à la créer ainsi que les sous-répertoires pour regrouper les fichiers d'un même usage. Voici le code :

# Création de l'arborescence de niveau 1.
for rep in $tabRep
  do
# Test si $rep existe et est un répertoire.  
  if [ ! -d $rep ]
      then
      echo "le repertoire $rep n'existe pas, je le créé\n"
# essai de créer le répertoire
      mkdir $rep || exit 1 # exit sera exécuté ssi mkdir échoue
  fi
done

Cette partie de programme montre :

L'utilisation de la structure for qui itére le code présent entre do et done pour chaque élement de la liste tabRep avec l'élément courant accessible par la variable $rep.
L'utilisation de l'opérateur logique || permet l'exécution conditionnelle de la seconde instruction. En effet la commande mkdir renvoie un code de sortie, si ce code est différent de 0 qui indique le succès alors la seconde instruction sera exécutée. En revanche si le code indique un succès, l'opération logique || sera forcément vraie donc l'interpréteur bash n'exécutera pas la seconde instruction. Si on n'arrive pas à créer un réperoire on sort du programme. On a probablement un manque de permission, cela ne sert donc à rien de continuer car on ne pourra rien enregistrer d'autre.

Les principes pour tester et créer les sous-répertoires sont les mêmes. Mais il faut préalablement créer les noms absolus des sous-répertoires à partir du répertoire courant. Voici le code correspondant à la création des noms de sous-répertoire :

# Extraction de la base du nom de $fichierUrl.
fichier=`echo $fichierUrl|cut -d . -f 0,1`

# Création des noms des sous répertoires.
repPageAsp="$BREPASP/""$fichier""_rep"; # Idem pour les 4 répertoires
# Liste contenant chaque sous répertoire.
tabRep="$repPageAsp $repPageLynxe $repPageContexte $repPageJournal";

L'existence de la page résultat et ce que l'on doit faire :

La partie suivante de l'algorithme est l'une des plus compliquées. Ce travail optionnel est intéressant car il permet de voir une autre structure de contrôle : la structure case. Ainsi que les appels de fonctions et le test de retour des fonctions. Le but est de tester si la page html existe déjà. Voir conception

if [ -f $ficHtml ]
    then
# Gestion des choix utilisateurs.
    echo "Le fichier $ficHtml existe déjà :" 
    echo "Taper E pour écraser le fichier et recommencer les téléchargements."
    echo "Taper C pour concaténer les résultats."
    echo "Taper Q pour quitter le programme maintenant."
    read choix
    case "$choix" in
	"C" | "c" )
	   echo "Vous concatenez le fichier"
	   # appelle la fonction de test_coherence 
	   test_coherence_corpus
           if [ $? -ne 0 ]; then echo "Etat du corpus incohérent"; exit 1; fi;

# Recopie le début du fichier, compose nouveau fichier d'URLs en faisant la
#différence du fichier URL passé en paramètre et de ce qui existe déjà.
	   concatenation
	   if [ $? -ne 0 ]; then echo "Concatenation impossible"; exit 1; fi;
	   action="C"  Sera testé par la suite.
	   break
	   ;;
	"E" | "e" )
	   echo "Vous écraser le fichier"
	   action="E"
           # On va continuer le traitement normal.
	   break
	   ;;	
	"Q" | "q" )
	   echo "Au revoir"
	   exit 0
	   ;;
	* ) # Cas par défaut.
	    echo "Vous ne respecter pas les consignes, au revoir"
	    exit 0
	    ;;	
    esac
fi

Les fonctions test_coherence_corpus et concatenation sont définies dans un fichier externe chargé de la manière suivante :

#importe les fonctions
. ./programmes/functions.sh

Ces fonctions semblent marcher mais elles sont trop longues pour être expliquées ici. L'important est que ces fonctions suivent les conventions UNIX en renvoyant 0 en cas de succès et -1 en cas d'échec.

La valeur de retour d'une fonction est sauvegardée par le shell dans la variable $?, elle est écrasée à chaque nouvel appel de fonction il ne faut surtout donc pas afficher sa valeur avant de la tester. Car ce que l'on testera ce sera la valeur de retour d'echo et non de notre fonction.