J’ai toujours considéré que pour certaines choses, la ligne de commande était plus que supérieure à l’interface graphique. Il est vrai que mon premier ordinateur n’avait pas d’interface graphique pour interagir avec l’utilisateur 😉
Voici deux exemples qui prouvent la puissance de la ligne de commande.
Ce matin, une mise à jour du noyau de mon Ubuntu Linux 8.04.1 LTS m’a été proposée.
Mise à jour qui a une nouvelle fois cassé le support de mon circuit wifi. J’ai donc appliqué la méthode que j’avais décrite il y a quelques semaines pour réactiver ma connexion sans-fil.
Par oubli – à 7 heures du matin, le cerveau n’est pas franchement des plus en forme, surtout tant que la caféine n’a pas été encore assimilé – j’ai bêtement oublié de nettoyer le code source compilé avec les droits administrateurs – ben ouais, quand cela touche le noyau, il faut que ce soit root qui s’active – bref, j’avais oublié un bête :
$ sudo make distclean
J’avais via Nautilus simplement envoyé le contenu à la corbeille, la vidant par la suite. Cependant, les données compilées avec les droits root ne pouvait pas être effacées 🙁
Le problème a été simplement résolu. J’ai ouvert un terminal, et j’ai rentré la ligne de commande suivante :
fred@fred-laptop:~$ cd .local/share/Trash/files
Les fichiers non effaçables étant présent, j’ai ensuite entré – en vérifiant deux fois ma ligne de commande car avec les droits root… – la ligne de commande :
sudo rm -rf *
Et la corbeille fut magiquement vide 😉
Autre exemple de la puissance de la ligne de commande. Depuis quelques temps, les logiciels de la Fondation Mozilla utilise pour leur version de développement le logiciel de suivi Mercurial, et le code source est compilé dans un répertoire en dehors du code source.
Ce qui permet non seulement des compilations plus rapides – n’est recompilé que le code changé – mais aussi de maintenir un code source propre.
Me faisant une copie de sauvegarde du code source une fois par jour, j’ai été confronté au problème de savoir comment archiver puis compresser le code source sans prendre en compte le répertoire de compilation du code source.
L’archivage étant effectué par la commande tar, et la compression par la commande bzip2.
La réponse m’a été donnée par le manuel de tar. Et voici ce que donne l’archivage puis la compression du code source de SeaMonkey :
$ tar cvfj moz-source-seamonkey.tar.bz2 --exclude=src/objdir-sm/* src/
Une petite explication rapide : cvfj = affichage bavard de l’opération qui archive l’ensemble des répertoires et des contenus (cvf) puis le compresse en bzip2 (j).
Le –exclude donnant le répertoire à ne pas traiter.
J’ai comparé avec l’option graphique. Il faut non seulement commencer par tout compresser (soit un peu plus de 360 MiO de données en plus), et il faut supprimer l’ensemble dans FileRoller, ce qui demande une opération de 2 minutes environ…
Sans oublier qu’on peut sans le faire exprès se tromper de répertoire et devoir tout recommencer…
Oui, je sais, cela peut faire peur à l’utilisateur lambda… Mais est-ce plus dur que d’apprendre à lire, à écrire ou à conduire un véhicule automobile ? 😉