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

[ok.Idriss]

Bonjour à tous.

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

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

[jsnooper]

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'`"

[ok.Idriss]

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 ).

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

Idriss

[jsnooper]

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

@++

[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

[jabbounet]

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:

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

[frp31]

Envoyé par Louson

Plutôt qu'un

Code :

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

Le cat est superflu, préférons :

Code :

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

[ok.Idriss]

Bonjour.

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

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

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.

[jabbounet]

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.

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.

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

[Sve@r]

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)...

[ok.Idriss]

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

Cordialement,
Idriss

[al1_24]

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

[Sve@r]

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

[hubhub]

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

[Sve@r]

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 bash :

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 bash :

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 bash :

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...

[Flodelarab]

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

[ok.Idriss]

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

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