Désormais, on peut sur les systèmes Unix modernes, faire toutes les opérations courrantes uniquement en utilisant une interface graphique, comme Kde ou Gnome. Alors pourquoi s'embêter à utiliser cette *** de ligne de commande, qui est complètement dépassée, qui date d'une époque où les ordinateurs ne savaient pas dessiner ? Tout simplement parceque la ligne de commande est loin d'être dépassée, et qu'au contraire, elle présente en de nombreuses occasions des avantages particulièrement utiles :
On peut tout simplement se rendre compte que taper des commandes au clavier est souvent au moins aussi rapide que d'aller chercher des applications dans un menu. Et un interpréteur de commandes bien configuré se chargera de nous rappeler l'orthographe exacte d'une commande, ce qui fait que l'argument comme quoi « il faut se rappeler » ne tient pas.
Attention, je ne suis pas un intégriste qui voudrait que tout le monde ne fasse que taper des commandes en vert sur fond noir. Je suis juste en train de suggérer aux utilisateurs qui commencent à avoir un peu de bouchon d'essayer, ne cerait-ce que de temps en temps, pour voir si par hasard vous n'y trouveriez pas des avantages insoupsonnés.
Pourquoi avoir écrit une telle introduction, alors qu'il en existe déjà des dizaines qui trainent sur le web ? Parcequ'aucune que de celles j'ai vues jusqu'à présent ne m'a satisfait. D'une part, elles étaient toutes axées sur bash, que je n'aime pas du tout, et d'autre part, elles laissaient un flou artistique sur certains points que j'estime très importants, probablement sous prétexte de simplification. Mais j'estime pour ma part que cette apparente simplification ne fera qu'ammasser des ennuis potentiels. Donc je préfère, en toute rigueur, ne pas la faire, tout en indquant que ce qui s'y rapporte n'a pas d'intérêt immédiat, qu'il est bon de l'avoir lu, mais pas nécessaire de le retenir. Les paragraphe de ce type seront écris en gris.
On avait déjà un interpréteur de commandes à l'époque de DOS. Beaucoup, d'ailleurs confondaient (et confondent encore) les deux. Pourtant, l'interpréteur de commandes n'est qu'une application comme les autres. Sa seule spécificité, c'est d'être celle exécutée au démarrage du système afin de fournir une première interface à l'utilisateur. Sous Linux, c'est la même chose, à ceci près qu'il n'est lancé qu'au moment où l'utilisateur a décliné son login et son mot de passe.
Le terme anglais, et usuel, pour désigner un interpréteur de commandes est « shell ». C'est ce terme-là que j'utiliserai à partir de maintenant, sans distinction typographique.
Parmi les données spécifiques à chaque utilisateur, figure justement, son « shell de login ». L'appellation est légèrement impropre, puisque dans ce champ, peut figurer le nom de n'importe-quelle application. Mais on choisit presque toujours un shell, même si son rôle se limite à lancer une interface graphique, où même parfois à rien du tout, pour ses qualités généralistes. Néanmoins, on utilise parfois d'autres choses. Ainsi, sur le serveur de la BNF, il existe un utilisateur sans mot de passe dont le « shell de login » est le logciel de consultation du catalogue.
Tout ceci pour dire que l'utilisateur a le choix du shell qu'il utilise. Dans cette introduction, pour ce qui est spécifique, je me référerai à zsh. Ce n'est pas le plus répendu, mais il s'agit indéniablement d'un des plus puissants. Si ce n'est pas celui que vous utilisez habituellement (ça se verra si les exemples ne marchent pas), pour peu qu'il soit installé chez vous, il suffit de taper zsh sur la ligne de commande pour en lancer une session.
Même si le shell est le point central de l'utilisation de la ligne de commande, le mécanisme fait presque toujours appel à des programmes externes, et ceci d'autant plus que la tâche est complexe. En fait, la plus part du temps, quand on tape une commande de la forme nom_de_commande arguments, ça se traduit presque toujours par l'exécution du programme nom_de_commande qui se trouve à un endroit particulier du disque dur.
La liste exacte des commandes installées sur un système est très variable, mais il y en a un certain nombre qui sont vraiment incontournables, et si elles ne sont pas installées sur votre système, c'est un tort. Quand j'utiliserai des outils un peu moins standards, je le mentionnerai, en indiquant si ça peut être utile de l'installer, et à quoi ça sert exactement.
L'unité de base d'une commande complexe, c'est tout simplement la structure
commande argument1 argument2 .... Ici,
commande est un ordre bien précis, et les
arguments sont des précisions à l'ordre. Ainsi, quand on tape
ls -l memoire.tex, l'ordre est ls (pour
list, et on lui donne les consigne supplémentaires d'utiliser un
format long, et de ne lister que le fichier memoire.tex.
À partir ce cette brique élémentaire, il est possible de construire des commandes plus évoluées, en utilisant deux constructions : le chaînage de commandes, qui permet d'en exécuter plusieurs en même temps ou à la suite, et les structures de contrôle, qui permettent de répéter des opérations, ou de tester des conditions. Mais nous y reviendrons plus tard.
Très souvent, les arguments qu'on donne à une commande sont des noms de
fichiers. Il est même courrant qu'on veuille effectuer une certaine action
sur tous les fichiers dont le nom se termine par
.tex, ou quelque chose dans ce style. La notation
* est la solution la plus répandue à ce genre de problème.
Quand on rencontre un mot comportant ce caractère, ça signifie
« considérer tous les fichiers dont le nom a cette forme », où
l'astérisque veut dire « n'importe-quoi ici ». Ainsi,
dea_*.tex désigne tous les fichiers dont le nom commence par
dea_ et se termine par .tex.
Sous DOS, la mise en place de ce principe était laissée entièrement à la
charge de la commande qui était appelée. Avec les shells Unix, cette tâche
est réalisée immédiatement au moment de la compréhension de la commande :
dès que le shell voit un mot qui contient ce caractère, il va immédiatement
chercher la liste des fichiers qu'il désigne, et insère cette liste
directement dans la commande, sans comprendre celle-ci. Ainsi, la
commande echo signifie simplement d'afficher un texte ;
pourtant, si on tape echo ***Erreur***, le shell va se
plaindre de ne pas trouver de fichier qui corresponde, alors qu'on ne
cherche pas du tout un tel fichier.
La coupure en mots est également de la responsabilité du shell. Imaginons
un répertoire qui contiennet trois fichiers : liste,
amis et liste amis (avec l'espace). Supposons
maintenant que nous tapions rm liste amis (où rm
veut dire remove). Qu'est-ce que ça veut dire ?