[Exercices] Liste d'exercices corrigés en shell script et bash

Bonjour à tous.

Je vous présente une nouvelle liste d'exercices corrigés avec un format plus adapté : Exercices shell scripts.

Citation:

---

Cet article regroupe des exercices corrigés en shell scripts Bash et autres langages shell compatibles. Les exercices sont classés par niveaux et peuvent posséder plusieurs solutions.

---

N'hésitez pas à laisser vos impressions, et vos propositions de énoncés et solutions en Bash voire même dans un langage shell compatible comme Ksh où autre. Si elles sont jugées pertinentes, elles seront intégrées à l'article. Dans ce cas, merci d'indiquer le niveau correspondant et l'exercice correspondant (on peux rajouter des niveaux au besoin).

Je remercie déjà tout les participants qui sont mentionnés ici.

Cordialement,
Idriss

Solution proposée:

Code:

---

1 2 3 4 5 6 7

#!/bin/bash   # Prendre tous les arguments et ajouter un saut de ligne pour un tri avec la commande sort tab=`echo $* | sed 's/ /\n/g' | sort`   # Afficher le résultat de tout le tableau en supprimant les sauts de lignes précédemment créés echo -e "Elements:\n`echo ${tab[*]}|sed 's/\n//g'`"

---

Bonjour jsnooper.

Merci de ta participation, toutefois cette solution ne répond pas à la contrainte qui est de passer par l'algorithme du tri à bulle (sinon un sort aurait suffit :aie: ).

En effet il existe différentes possibilités pour trier des éléments et la tienne est efficace mais ne répond pas à cette contrainte "pédagogique".

Toutefois, lorsque j'aurais un peu de temps, ça vaudrait peut être le coup de faire un exercice plus général sur les façons de trier des éléments. Je vous laisse exprimer vos avis dessus et éventuellement proposer d'autres solutions. Qu'en pensez-vous ?

Encore merci :ccool:

Idriss

Ok... Désolé de ne pas avoir bien lu l’énoncé !

@++

Plutôt qu'un

Code:

---

1 2 3 4

cat $fichier | while read line do ... done

---

pour la lecture ligne par ligne (exercices pour confirmés)

Le cat est superflu, préférons :

Code:

---

1 2 3 4

while read line do ... done < $fichier

---

j'ai parcouru rapidement la liste d'exercice, c'est assez intéressant, par contre je ne vois pas ou est le focus pédagogique...

je m'explique, quand on prend par exemple le premier exercice:

Citation:

---

Créer un script qui demande à l'utilisateur de saisir une note et qui affiche un message en fonction de cette note :

"très bien" si la note est entre 16 et 20 ;
"bien" lorsqu'elle est entre 14 et 16 ;
"assez bien" si la note est entre 12 et 14 ;
"moyen" si la note est entre 10 et 12 ;
"insuffisant" si la note est inférieur à 10.

---

quel est le but pédagogique, quel est l'élément du langage mis en valeur par ce type d'exercice?

ici par exemple ce serait la manipulation des structures de contrôle et plus particulièrement les structure conditionnelle....

bref je pense que avoir une introduction sur les éléments de langage à manipuler est important pour ce type d'exercice.

note pour ce premier exercice il est aussi possible d'utiliser select.
http://homel.vsb.cz/~dvo25/reily/boo...sh/ch05_04.htm

Citation:

---

Envoyé par Louson

Plutôt qu'un

Code:

---

1 2 3 4

cat $fichier | while read line do ... done

---

pour la lecture ligne par ligne (exercices pour confirmés)

Le cat est superflu, préférons :

Code:

---

1 2 3 4

while read line do ... done < $fichier

---

---

j'ajouterai meme que la variable ne sert à rien !!!
la variable de read est REPLY elle existe déjà et elle est chargée aussi si on utilise une variable personnelle !! bref c'est une perte de temps systeme et de memoire d'en charger 2 plutot qu'une

Bonjour.

Merci à tous pour ces suggestions, je ferais de tests et mettrai à jour la liste quand j'aurais un peu de temps :ccool:

J'essayerai d'adapter par rapport à la remarque de Louson qui est tout à fait juste, dans un premier temps. Ensuite pour ce qui est d'un focus sur les compétences de chaque exercice, c'est une bonne idée également :ccool:

Citation:

---

la variable de read est REPLY elle existe déjà et elle est chargée aussi si on utilise une variable personnelle !! bref c'est une perte de temps systeme et de memoire d'en charger 2 plutot qu'une

---

Hum, il ne me semble pas ... j'ai re-testé : REPLY n'est que la variable par défaut d'un read.

read => $REPLY existe avec la valeur lue
read line => $line existe avec la valeur lue mais pas $REPLY

Un exemple pour s'en convaincre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

[idriss@hp-dv6:~]$ cat fichier.txt toto titi tata [idriss@hp-dv6:~]$ cat test.sh #!/bin/bash   fichier=fichier.txt while read do echo "LINE : "$line echo "REPLY : "$REPLY done < $fichier [idriss@hp-dv6:~]$ ./test.sh LINE : REPLY : toto LINE : REPLY : titi LINE : REPLY : tata [idriss@hp-dv6:~]$ cat test2.sh #!/bin/bash   fichier=fichier.txt while read line do echo "LINE : "$line echo "REPLY : "$REPLY done < $fichier [idriss@hp-dv6:~]$ ./test2.sh LINE : toto REPLY : LINE : titi REPLY : LINE : tata REPLY : [idriss@hp-dv6:~]$

---

Et personnellement je préfère nommer mes variables dans la mesure où ça ne déteint pas sur les performances.

:merci:

Citation:

---

Envoyé par ok.Idriss

Bonjour.

Et personnellement je préfère nommer mes variables dans la mesure où ça ne déteint pas sur les performances.

:merci:

---

Confirmé l'impact semble faible au moins pour des fichiers de petites tailles.

j'ai fait un test rapide avec un fichier de 10000 lignes différentes chaque ligne contenant 70 caractères

j'ai le résultat suivant en utilisant time pour mesurer le temps d’exécution des scripts.

Citation:

---

avec $REPLY
real 0m13.577s
user 0m0.749s
sys 0m0.890s

avec read $line
real 0m13.595s
user 0m1.077s
sys 0m0.765s

---

ensuite ce genre de test peut varier en fonction de la machines, et de tout un tas de facteurs mais bon c'est pas comme si je mesurais les perf d'une système sensible ;)

Citation:

---

Envoyé par ok.Idriss

Et personnellement je préfère nommer mes variables dans la mesure où ça ne déteint pas sur les performances.

---

Moi aussi. Et n'oublions pas ceux qui bossent sur des shells plus anciens où la variable REPLY n'existe pas (style Bourne Shell ou Korn Shell)...

Bonjour.

J'ai effectué une première mise à jour de la liste en améliorant les parcours des fichiers suite à la remarque de Louson (merci à lui).

Pour le focus, on verra plus tard, mais je suis totalement pour :ccool:

Cordialement,
Idriss

Citation:

---

Envoyé par Sve@r

Et n'oublions pas ceux qui bossent sur des shells plus anciens où la variable REPLY n'existe pas (style Bourne Shell ou Korn Shell)...

---

La variable REPLY existe en Korn Shell 88

Citation:

---

Envoyé par al1_24

La variable REPLY existe en Korn Shell 88

---

Désolé, j'ai lancé ça au bluff n'ayant pas de ksh pour vérifier :mouarf:

Bonjour :)

je vous propose d'utiliser la fonction grep avec l'option -c

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

function calcul { repertoire=`ls -l ${nom} | grep -c "^d"` echo "Le nombre de répertoire est de $repertoire" executable=`ls -l ${nom} | grep -c "^[-]..x"` echo "Le nombre de fichiers exécutables est de $executable" fichier=`ls -l ${nom} | grep -c "^.*"` echo "Le nombre total de fichiers est de $fichier" }   nom=${1}   if [ -z ${nom} ] then echo "Entrez un nom de répertoire" read nom calcul ${nom} else calcul ${nom} fi

---

Salut

Merci de ton effort mais maintenant, on va un peu tailler dans le vif.
Déjà, tu fais 3 fois "ls -l" ce qui est une opération assez coûteuse. Tu pourrais factoriser un peu ça et stocker le résultat dans une variable que tu réutiliserais 3 fois.
Ensuite pareil pour l'appel calcul. Si le nom est vide lancer calcul sinon lancer calcul. Surtout que nom est issu de $1 (moi j'admire les gens qui ont une pièce dans la main droite mais qui la font d'abord passer dans la main gauche avant de payer => pourquoi ne pas utiliser directement $1 ???) et donc il ne peut pas être vide (sauf si $1 est vide mais dans ce cas ça veut dire qu'il n'y a pas d'argument donc $# vaut 0). De plus, s'il y a un paramètre $1 alors peut-être qu'il y en a plusieurs $2, $3 $4 dont l'utilisateur aimerait aussi avoir le calcul...

Et enfin tu appelles calcul en lui passant $nom comme paramètre. Or, la fonction n'utilise pas ce paramètre (qui est "$1" pour elle) mais directement la variable globale $nom. Ca c'est le pire...

Donc en appliquant ces remarques, cela donnerait le code suivant

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

#!/bin/sh   function calcul { ( repertoire=`ls -l "$1"`   echo "Le nombre de répertoire est de " `echo "$repertoire" | grep -c "^d"` echo "Le nombre de fichiers exécutables est de " `echo "$repertoire" | grep -c "^[-]..x"` echo "Le nombre total de fichiers est de " `echo "$repertoire" | grep -c "^.*"` ) }   if [ $# -ne 0 ] then for nom in $* do calcul $nom done else echo "Entrez un nom de répertoire" read nom calcul $nom fi

---

Ca c'était le plus facile. Ensuite, plus délicat: rendre ta fonction plus universelle. En effet, ta fonction fait le calcul puis affiche le résultat. Mais peut-être que l'utilisateur ne veut pas afficher le résultat. Peut-être qu'il désire juste avoir les valeurs pour s'en servir lui dans des calculs plus complexes.

Donc on va réduire la fonction à son travail le plus basique et le plus atomique: récupérer juste les valeurs et les renvoyer à l'appelant qui, lui, les utilisera comme il le sent

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#!/bin/sh   function calcul { ( repertoire=`ls -l "$1"`   nbr=`echo "$repertoire" | grep -c "^d"` nbx=`echo "$repertoire" | grep -c "^[-]..x"` nbf=`echo "$repertoire" | grep -c "^.*"` echo $nbr $nbx $nbf ) }

---

Et voici une façon possible de s'en servir

Code:

---

1 2 3 4 5 6

#!/bin/sh nom=$1 set `calcul "$nom"` echo "Le nombre total de répertoires de $nom est $1" echo "Le nombre total d'exécutables de $nom est $2" echo "Le nombre total de fichiers de $nom est $3 mais sans les exécutables cela donne alors `expr $3 - $2`"

---

PS: les parenthèses dans la fonction c'est en plus pour rendre les variables locales à la fonction. Pour éviter par exemple une collision entre le "nbx" de la fonction et une variable nommée aussi "nbx" dans ton code principal. Sans les parenthèses, le nbx de la fonction écrase alors le nbx du code principal. Hé oui, les globales en shell c'est utile mais ça a aussi ses désavantages...

Ceci a l'avantage d'être un forum. Je préférerais une page de liens vers les vrais questions posées par les vrais gens sur de vrais situations, rangés par thème. Les problèmes posés ici sont trop subjectifs et ex nihilo.

(perso, je n'en résous aucun par bash mais sed ou awk)

Cela dit, bonne initiative :ccool:

Bonjour.

Pour répondre à Flodelarab. Ceci est une liste d'exercice plutôt orientée débutant. Elle n'a pas pour vocation à lister des cas pratiques que l'on rencontre dans le cadre de son travail mais simplement de permettre aux débutants de mettre en pratique des structures shells.

Il serait difficile de recenser toutes les questions pro dans un articles pour deux raisons. D'une part parce qu'il y en a beaucoup. Les habitués des forums shells Unix et Linux répondent régulièrement à des questions shells avec des solutions diverses et variés : sed et awk sont très présents mais pas que : parfois join c'est pratique, parfois sort et uniq suffisent, parfois cut suffit aussi et est plus léger, parfois grep ou même les fonctionnalités que permettent bash 3 (comme les condition sur expressions régulières) sont suffisantes pour répondre à des problèmes. D'autre part parce que cela serait inutile : les problématiques résolues sont nombreuses avec des réponses pertinentes, il suffit de faire des recherche. Je ne vois pas l'utilité de référencer 90% des questions posées dans ces forums sur une page, ça n'aiderait pas plus :aie:

Bref, chaque article a ses vocations. Pour les problématiques précises et dans un contexte professionnel soit on trouve des problématiques similaires résolue par des réponses riches et pertinente sur le forum ce qui arrive très souvent. Soit on la pose et très probablement, une solution sera trouvée rapidement si le posteur fait les efforts nécessaires.

Et quant au fait de n'utiliser que sed et awk : je résout beaucoup de problèmes avec mais c'est pas systématiquement la solution la plus adaptée et surtout la plus performante (j'ai eu à de plusieurs reprises des cas où la commande join à titre d'exemple était beaucoup plus efficace même si c'était faisable avec gawk, pareil pour bash en lui même).

Bon voilà, on peux envisager d'intégrer des exercices avec des solutions en sed et awk, encore faut-il en proposer...

Cordialement,
Idriss

j'ai pas tout lu mais en tout cas merci, ça m'a permis d'apprendre pour

Code:

---

1 2 3

while read line; do .... done < $file

---

qui m'a permis de gagner du temps sur le traitement d'un dossier avec tout plein de fichiers dedans où je ne voulais que manipuler que certains

:ccool:

Dans II-C. Exercice 3 - Calculatrice

Le code rencontre un problème en prenant * en argument. En effet, appeler

Code:

---

script.sh 10 * 10

---

passera réellement comme argument au script :

Code:

---

10 fichier1 fichier2 ... 10

---

* joue son rôle de wildcard, et est remplacé par tout le contenu du dossier en cours.

Et il n'y a pas de solution simple pour éviter l'expansion de *. Sauf surveiller l'utilisateur, et le forcer à entrer * entre des quotes.

Plus d'infos : ici, principalement la première réponse, reprenant l'article de Simon Tatham.

On est loin des considérations d'un débutant, mais ces mêmes débutants risquent de se demander pourquoi leur script fait n'importe quoi, même en copiant la solution.

Citation:

---

Envoyé par stan0000

Le code rencontre un problème en prenant * en argument. En effet, appeler

Code:

---

script.sh 10 * 10

---

passera réellement comme argument au script :

Code:

---

10 fichier1 fichier2 ... 10

---

* joue son rôle de wildcard, et est remplacé par tout le contenu du dossier en cours.

---

Ce n'est bien entendu pas la faute du code ni du codeur !!! Le code est prévu pour à recevoir une étoile, à l'utilisateur (sensé connaitre son environnement de travail) de lui passer une étoile...

Citation:

---

Envoyé par stan0000

Et il n'y a pas de solution simple pour éviter l'expansion de *. Sauf surveiller l'utilisateur, et le forcer à entrer * entre des quotes.

---

Les bons tutos de shell ont tous un chapitre sur la façon de neutraliser les métacaractères

Code:

---

1 2 3

script.sh 10 \* 10 script.sh 10 '*' 10 script.sh 10 "*" 10

---

Citation:

---

Envoyé par stan0000

On est loin des considérations d'un débutant, mais ces mêmes débutants risquent de se demander pourquoi leur script fait n'importe quoi, même en copiant la solution.

---

On part toujours du principe qu'un débutant, tout débutant qu'il soit, connait quand-même les bases du langage. Il n'est débutant que dans son inexpérience à bien assembler ces bases, et non dans sa méconnaissance desdites bases...