TP2 - Environnement et scripts personnels

Dans cette seconde partie, nous allons créer un certain nombre de scripts shell (il s’agit de fichiers texte contenant des commandes du shell). La plupart pourront vous être utiles par la suite, nous commençons donc par organiser l’environnement de travail de façon à pouvoir classer les scripts et les utiliser comme de nouvelles commandes du système.

Création d’un répertoire pour ranger vos scripts

Avec la commande mkdir, créez un répertoire bin dans votre répertoire de travail par défaut (peut-être existe-t-il déjà ?). Positionnez-vous dans bin et créez à l’aide d’un éditeur de texte de votre choix (vim, gedit, etc, mais surtout pas LibreOffice) un fichier essai contenant un script shell qui affiche ses deux premiers paramètres sur 2 lignes séparées.

Exemple :

essai un deux

doit afficher :

param 1 : un
param 2 : deux

Indice

Rappelez-vous que $1 et $2 représentent les deux premiers paramètres passés au script.

Voir le cours : Les variables spéciales

Voir la correction

#!/bin/bash
echo "param 1 : $1"
echo "param 2 : $2"

Rendez-ce fichier exécutable (chmod +x essai) et lancez-le (essai un deux).

Il faut maintenant ajouter le répertoire bin que vous venez de créer dans la liste des répertoires où le système va chercher les commandes (PATH), et ce de manière permanente.

Pour ce faire :

éditez votre fichier .bashrc et modifiez-le si nécessaire ;
ouvrez une nouvelle fenêtre terminal ;
lancer essai dans cette fenêtre pour vérifier que ça fonctionne.

Pourquoi cela ne marche-t-il pas dans l’ancienne fenêtre ?

Voir le cours : Ordre des initialisations

Vous disposez maintenant d’un répertoire pour ranger vos commandes personnelles, répertoire qui vous est accessible quel que soit votre répertoire de travail.

Substitutions, vous avez dit substitutions ?

Voir le cours : Les variables (suite) (la substitution de commandes)

Essayez la commande essai *. Expliquez ce qui se passe.

Essayez la commande date.

Essayez la commande essai $(date). Expliquez ce qui se passe.

Combien d’utilisateurs ?

La commande who affiche la liste des utilisateurs connectés (1 par ligne). La commande wc compte les lignes, les mots et les caractères contenus dans les fichiers passés en paramètres ou sur son entrée standard si aucun fichier n’est passé.

Essayez who. Réessayez who en redirigeant sa sortie sur l’entrée de wc (avec un tube).

En utilisant who en conjonction avec wc (faire man wc pour déterminer la bonne option), créer dans votre répertoire bin une commande hmu qui affiche :

hmu
Il y a XX utilisateurs connectés.

XX est bien sûr le nombre d’utilisateurs effectivement connectés.

Indice

Combinez who et wc -l avec un tube pour obtenir le nombre d’utilisateurs, stockez le résultat dans une variable, puis affichez le message avec echo.

Voir le cours : Redirections (suite) (les tubes)

Voir la correction

#!/bin/bash
nb=$(who | wc -l)
echo "Il y a $nb utilisateurs connectés."

Comme vous êtes seuls connectés sur le poste de travail, cette commande présente peu d’intérêt.

Connectez-vous au serveur avec la commande :

ssh votrelogin@server

puis votre mot de passe et re-testez who et votre commande hmu.

Tapez exit pour sortir de la connexion ssh.

Soyons prudents…

Unix est parfois un peu violent et ne donne pas droit à l’erreur. Pour éviter ça, on va écrire une commande del qui envoie les fichiers passés en paramètres dans un répertoire (baptisé poubelle) de votre répertoire de travail par défaut (HOME directory). On utilisera del pour effacer des fichiers, ainsi en cas de fausse manœuvre, on pourra récupérer les fichiers dans le répertoire poubelle. De temps à autre, on ira vider la poubelle avec la commande rm.

Revenez au répertoire de travail par défaut et créez le répertoire poubelle.

Créez un fichier del dans votre répertoire bin. Ce fichier devra contenir un script permettant de déplacer (commande mv) tous les fichiers passés en paramètres dans le répertoire poubelle.

Rendez le fichier del exécutable et testez-le, en commençant par des fichiers bidons, créés pour l’occasion (on peut créer un fichier vide avec la commande touch : touch toto titi créera les fichiers toto et titi).

Indice

Utilisez un chemin absolu vers votre poubelle (~/poubelle ou $HOME/poubelle) plutôt qu’un chemin relatif, sinon le script ne fonctionnera que si on l’appelle depuis un répertoire précis. $@ permet de récupérer tous les paramètres passés au script pour les donner à mv.

Voir le cours : Les caractères et chemins spéciaux (le ~)

Voir la correction

#!/bin/bash
mv "$@" ~/poubelle

Compilation paramétrée

Pendant une session de travail sous Unix, on effectue souvent un cycle édition-compilation-exécution et on est donc amené à taper successivement des commandes du type :

gedit tp.c &

gedit est un editeur de text, cela peut être autre chose comme nano, vim, etc

puis de manière répétitive :

cc tp.c -o tp
tp

Comme il y a (parfois) des erreurs de compilation, on redirige la sortie des erreurs du compilateur sur un fichier qu’on peut ensuite consulter avec more ou less.

On se propose ici d’automatiser quelque peu ce processus répétitif.

Créez (toujours dans votre répertoire bin), un fichier comp qui compile un programme C en redirigeant la sortie erreur dans un fichier comp.log. Rendez ce fichier exécutable et testez-le (par exemple sur le programme bravo.c récupéré dans la première partie).

Modifiez le fichier comp :

pour qu’il produise un programme exécutable de même nom que le paramètre (on devra supposer que ce paramètre ne contient pas l’extension .c).
pour qu’il teste le résultat de la commande cc et soit lance l’exécution (en cas de succès), soit affiche comp.log en utilisant la commande less. Ainsi, l’appel comp bravo doit compiler le fichier bravo.c et le lancer si la compilation réussit ou bien produire un fichier comp.log et l’afficher si la compilation échoue.

Indice

cc "$1.c" -o "$1" 2> comp.log compile en nommant l’exécutable comme le paramètre. Le code de retour de cc (0 si succès) peut directement servir de condition à un if, pas besoin de le tester “à la main”.

Voir le cours : Les conditionnelles

Voir la correction

#!/bin/bash
if cc "$1.c" -o "$1" 2> comp.log
then
    ./"$1"
else
    less comp.log
fi

Processus

Voir le cours : Les processus

Lancez la commande comp de l’exercice précédent en arrière-plan (avec le &) puis immédiatement la commande ps (qui affiche la liste de vos processus actifs).

Lancez ensuite la commande ps -ef pour avoir la liste de tous les processus actifs du système.

Pour voir le début de la liste, créez un tube de ps -ef sur more:

ps -ef | more

Quel est le numéro (PID) du processus init ou systemd ?

Créez une nouvelle fenêtre avec la commande :

xterm -T nouveau &

le & permet de garder la main dans le terminal d’origine

Tapez la commande ps -fU $LOGNAME pour avoir la liste de tous vos processus en format long.

Notez le numéro (PID) du processus xterm que vous venez de créer. Quel est le numéro de son père (PPID) ? Ce processus a-t-il d’autres fils ?

Avec la commande kill, tuez (arrêtez) le processus xterm (nouveau) :

kill -KILL <PIDduProcessus>

Voir le cours : Gestion des processus (signaux)

Que se passe-t-il ?

Exercice bonus (pour les plus rapides)

Ecrire un script shell (à ranger dans $HOME/bin) qui à la fin de chacun des fichiers dont le nom est passé en paramètre (supposés être des sources C, C++ ou Java) ajoute la ligne :

/* ------- Fin de <NomDuFichier> ------- */

Voir la correction

#!/bin/bash
for f in "$@"
do
    echo "/* ------- Fin de $f ------- */" >> "$f"
done