Salut
Attention aux emplois inusités de l'infinitif en lieux et place du participe passé...
flaschgordon a écrit :
Citation :
#!bin/bash
#Presentation du groupe
echo "__________________________________"
echo "| Projet Bash 2011-2012 |"
#debut du programme
while [$Url -ne '.'] #boucle de saisie d'url do
echo "Madame Monsieur"
echo "Veuillez entrez une Url"
echo "Tapez '.' lorsque la saisie est terminer" #condition de fin de boucle de saisie d'url
read Url >> ListeUrl # saisie de l'url
done 0=i
#boucle de lecture ligne par ligne du fichier listeUrl
while [] # tant que la ligne suivant du fichier texte est saisie do
wget -r -i ListeUrl -P Contenu -tries=10 $Url # recuperer le contenue du site a l'adresse se trouvant dans le fichier ListeUrl
done
sed cat Contenu | sort | uniq | -c
|
|
Bon, petit récapitulatif des pb de ton scripts
1) le shell est très limité comme langage. C'est fait exprès pour qu'il perde le moins de temps possible à essayer de comprendre ce que tu lui as tapé. Corollaire, il te faut être super rigoureux dans ta syntaxe. Et un de ses impératifs est de bien séparer les éléments.
Donc while [$Url -ne '.'] ne sera pas compris pas alors que while [ $Url -ne '.' ] le sera.
Accessoirement, -ne est fait pour comparer du numérique. Comparer des chaines c'est = ou != donc while [ $Url != '.' ]
Ce qui nous amène au pb suivant (mais là c'est un truc très pointu): un des gros dangers de cette syntaxe c'est que si l'utilisateur ne rentre rien, la variable $Url sera vide et que dans ce cas, le shell verra while [ != '.' ]
Cependant, l'opérateur != veut impérativement 2 opérandes et si le shell n'en voit qu'un, il ne s'en sort plus (toujours le pb du temps d'interprétation)
Pour pallier ce souci, encadrer la variable par des guillemets => while [ "$Url" != "." ]
Ainsi, même si $Url est vide, le shell verra while [ "" != "." ] et comprendra quand-même l'instruction...
2) séparer les instructions. read sert à lire une info dans l'entrée standard et à la stocker dans une variable, rien d'autre (et surtout elle n'affiche rien). Donc read Url >> listeUrl redirigera ce qu'affiche l'instruction read (donc pas grand chose) dans le fichier listeUrl. C'est syntaxiquement correct mais cela ne fera pas ce que je crois que tu veux faire.
Si tu veux faire saisir une url et la stocker dans un fichier, alors 2 étapes
read Url
echo "$Url" >> listeUrl
3) la lecture d'un fichier => là il faut bien comprendre les principes
read sert à lire l'entrée standard et à stocker cette entrée dans une variable. Le marqueur de fin de lecture c'est la touche <return>. Or, coup de bol, chaque ligne d'un fichier se termine par un <return>.
De plus, cette commande, comme toute commande Unix, renvoie un état. Et il se trouve que cet état est à faux si elle ne lit rien. Donc on peut boucler sur un while read (rappel: while peut vérifier toute commande quelle qu'elle soit) et ainsi rester dans la boucle tant que qqchose a été lu.
Et enfin l'entrée standard, utilisée par défaut pour le read, peut être redirigée à partir d'un fichier via l'opérateur "<" (et aussi, si on le désire, d'une commande via un pipe).
Ce qui donne la structure générale suivante
Code :
- while read ligne
- do
- echo "ligne lue: [$ligne]"
- done <listeUrl
|
Ainsi, chaque ligne lue sera stockée dans la variable "$ligne" puis traitée dans la boucle. Et quand tout le fichier aura été traité, le read ne lisant plus rien renverra "faux" et le while s'arrêtera. Et cette syntaxe démontre (s'il était nécessaire), que la structure while ... do ... done est compris comme étant qu'une seule et unique commande (puisque la redirection <listeUrl s'applique à la commande qui la précède)
Donc voilà. J'espère qu'avec ces quelques notions tu t'en sortiras. Si tu veux, tu as un cours complet de shell ici => http://fr.lang.free.fr/cours/Shell_v2.0.pdf
Tableaux associatifs ??? Cette notion existe en php, existe en perl, existe en Python... mais je ne savais pas qu'elle avait été intégrée dans le shell. De mon coté j'étais resté aux tableaux simples (ceux qui ont un indice) et ce genre de tableau n'est seulement connu que des shells évolués (ksh, bash et au delà). Et généralement j'arrive toujours à m'en passer surtout si je programme des scripts portables pour tout type de shell...
Message édité par Sve@r le 24-11-2011 à 22:02:30