Pour aller plus loin avec la ligne de commande

En 1992, un collègue du DEA Image de l'université Jean Monnet de Saint-Étienne, fait démarrer son PC en me disant : « tu vois ça c'est unix », il s'agissait bien sûr d'une des premières versions de LINUX. J'avais alors été plutôt sceptique sur cet imbroglio de messages au démarrage et sur l'aspect plutôt spartiate de l'environnement graphique. Parallèlement, nous travaillions sur des « miniprojets » (sorte de projet de fin d'études) axés sur l'implantation d'algorithme de traitement et d'analyse d'image.

À l'époque, nous utilisions un compilateur C du commerce n'exploitant pas le mode protégé du processeur Intel, et nous nous trouvâmes face au problème aberrant de la mémoire segmentée par paquet de 64 ko. Cette limitation rendait très difficile le chargement d'images numériques en mémoire. C'est finalement « grâce » à ce problème que nous sommes tombés sur un compilateur (djgpp) en ligne de commande capable d'exploiter le mode protégé des processeurs des Pcs(2) et ainsi de lever cette limitation.

Ce compilateur a été une révélation dans le sens où je me suis aperçu que des gens distribuaient gratuitement des outils qui allaient enfin me permettre de travailler confortablement.

Certains miniprojets du DEA avaient lieu à l'école des Mines de Saint-Étienne, et c'est là que j'ai eu les premiers contacts avec cette « chose » qu'est unix. Premiers contacts désagréables : impossible de trouver un lecteur de disquette dans ce fatras de machines, des éditeurs de texte pour programmer, dont tout le monde vantait les mérites, nécessitant 23 doigts et une mémoire d'éléphant pour arriver à insérer un caractère en fin de ligne, des utilisateurs à la limite du fanatisme, devenant même hargneux et sectaires lorsque je mentionnais mon expérience de développeur débutant en C avec Turbo C… Cependant il émanait de ce laboratoire qui utilisait les ressources de ce réseau unix, une certaine liberté d'action qui m'a d'emblée séduit : il était apparemment possible d'utiliser les processeurs de plusieurs machines, chaque utilisateur semblait avoir créé son propre environnement de travail, personne ne parlait de « rebooter » ou de « plantage », certains s'attelaient à des projets de logiciels ambitieux, d'autres rédigeaient des documents d'allure professionnelle, il n'était pas question de pirater un logiciel du commerce puisque tous les outils semblaient être à portée de main pour travailler.

En 1993, débutant une thèse au laboratoire Ingénierie de la Vision de la faculté de sciences à Saint-Étienne, j'entrepris d'installer une version de gcc (compilateur C de chez gnu) et de comprendre comment fonctionne ce fameux LATEX (système de préparation de document qui a généré le document que vous avez sous les yeux). Le fait que l'Université soit connectée au réseau Renater(3) a bien sûr grandement aidé à mener à bien ce projet parsemé d'embûches qui m'a permis de me sensibiliser à l'environnement d'unix. J'ai été alors fasciné par l'immensité du système, son aspect ouvert donnant une sensation d'infini, effrayant de complexité. Mais cette complexité était, me semblait-il, le prix de la liberté, la liberté de pouvoir contrôler cette machine qu'est l'ordinateur.

Les années qui ont suivi, je les ai consacrées en partie à l'administration d'un système unix pour l'équipe de recherche et les étudiants, c'est également à cette époque que j'ai découvert et me suis investi dans l'unix que je pouvais emporter à la maison : LINUX. Je passais alors de simple utilisateur de l'informatique à acteur qui tentait de comprendre les rouages de ce meccano géant qu'est un système d'exploitation. La motivation venait bien sûr du fait que toutes les pièces de ce meccano étaient accessibles et documentées. J'avais la sensation de pouvoir potentiellement comprendre les fondements de l'informatique tout en étant conscient que cela me demanderait sans doute un temps infini…

La rencontre virtuelle via les forums de discussion, avec la communauté de « bricoleurs » de chez gnu et LINUX a été pratiquement une prise de conscience quasi politique, une autre vision de la démarche scientifique. Je trouvais enfin des êtres humains désirant « faire avancer le schmilblick » sans arrière-pensée de capitalisation de l'information. Malgré tout, si les logiciels libres peuvent s'intégrer - et s'intègrent - dans l'économie de marché, je reste aujourd'hui admiratif vis-à-vis de cette idée de diffuser les connaissances et de s'assurer qu'elles puissent toujours être diffusées. C'est sans doute à ce prix que le commun des mortels, utilisateur de l'outil informatique gardera son indépendance d'esprit et sa liberté de choix.

J'ai entrepris de rédiger ce manuel lorsqu'en 1999, le responsable de maîtrise de l'IUP Vision de Saint-Étienne m'a demandé de dispenser quelques heures de cours pour présenter aux étudiants le système unix. Le document était alors composé d'un « petit guide de survie » présentant les fonctionnalités de base à connaître pour survivre devant un ordinateur géré par un unix. J'ai ensuite décidé de compléter ce document, en tentant de présenter ce qu'un utilisateur doit savoir pour se débrouiller sous unix. Ce manuel ne contient donc aucune allusion à l'administration d'un système.

Il ne se veut pas non plus un guide de référence(4), mais plutôt une sensibilisation à la « philosophie » d'unix. On trouvera donc beaucoup de pistes à explorer et jamais de présentation systématiquement détaillée. Comme disait mon professeur de Taï Chi au sujet d'un stage qu'il avait effectué sur le Yi Qing, si unix était un livre, ce document serait l'équivalent de passer son doigt sur la couverture pour y enlever la poussière…

Les informations présentées ici font partie des connaissances que j'ai acquises ces dernières années et dont je fais usage régulièrement, il s'agit donc à mon humble avis d'informations utiles et directement exploitables et non pas de fonctionnalités obscures. J'ai tenté de les présenter avec l'idée de m'adresser à un novice, dans le but de le convaincre de l'intérêt qu'il y a à apprendre unix. En outre, si la plupart des informations de ce manuel sont adaptées à n'importe quel unix, il est évident que LINUX est notre unix de « référence » de même que les outils présentés le sont dans leur version du projet gnu. Il ne s'agit pas d'un choix sectaire, mais simplement de l'exploitation de la grande disponibilité de ces outils.

L'utilisateur novice d'unix et de LINUX en particulier cherche souvent des informations pour installer ce système d'exploitation sur sa machine, pour savoir s'il faut partitionner son disque dur ou en acheter un autre, pour connaître la distribution(5) de LINUX qui lui conviendrait le mieux, pour savoir comment, une fois ladite distribution installée, il est possible d'avoir du son, d'utiliser son scanner, de configurer sa connexion Internet, etc. Ce manuel ne traite ni de l'installation, ni de l'administration d'un système unix, mais donne le savoir-faire nécessaire pour s'y attaquer. D'autres interrogations concernent les équivalents des logiciels de bureautique(6), de jeux, etc. Il ne sera donc pas question dans ce manuel ni des équivalents en logiciels libres des tableurs et autres traitements de texte, ni de l'utilisation des célèbres bureaux qu'on trouve aujourd'hui sous LINUX : Kde et Gnome. Nous ne pouvons que vous conseiller de vous procurer l'excellent Simple comme Ubuntu (Roche, 2010) pour trouver des réponses s'appuyant sur la distribution Ubuntu.

Les outils présentés ici sont ceux que l'on peut retrouver sur n'importe quel unix. L'accent est donc mis sur l'usage des commandes et de leur utilisation interactive ainsi que dans le cadre de scripts ; il sera donc davantage question de clavier que de souris. Ce manuel a d'ailleurs pour objectif de convaincre le lecteur de l'intérêt de cette approche dans le cadre de l'apprentissage d'unix.

Il est important de noter que le titre de ce manuel est un mensonge éhonté. Le contenu de ce document ne se veut pas être une présentation d'unix, ou même des unix, ni des standards tels que Posix. L'unix de référence ici est GNU/LINUX, car c'est sans doute aujourd'hui le plus accessible et le plus utilisé. Cependant, la majeure partie des outils présentés dans ce manuel peuvent être utilisés tels quels sur n'importe quel unix. Lorsque ça ne sera pas le cas, nous tenterons d'insérer ce joli panneau dans le paragraphe.

Ce manuel est avant tout un manuel destiné aux débutants, il a donc pour objectif d'être didactique et tente donc de ne pas noyer le lecteur dans un fatras de détails techniques. Encore une fois, le titre pourrait induire le lecteur naïf que vous n'êtes pas, en erreur : vous ne saurez pas tout sur unix ! Aux endroits où apparaîtra ce panneau, j'ai introduit quelques concepts un peu plus « pointus » qu'il est, dans un premier temps, inutile de lire, mais qui corrigent certaines imprécisions.

Les pages se lisent de gauche à droite et de haut en bas et pour donner l'impression d'une cohérence globale, ce manuel est divisé en chapitres dont les titres sont :

• unix et les logiciels libres : une présentation de la naissance d'unix, du lien avec les logiciels libres. Un chapitre non technique, assorti de considérations philosophico-politico-économicoéthiques douteuses ;
• Petit guide de survie : chapitre présentant les concepts de base d'unix (notions d'utilisateurs, de fichiers, de processus, etc.) ;
• La boîte à outils : contient une description de quelques-uns des outils du grand meccano. Ce chapitre permet d'avoir une idée de la souplesse apportée par l'homogénéité de tous ces outils ;
• Communiquer ! : présente les outils axés sur le réseau, la communication entre utilisateurs, entre machines, le transfert de fichiers, l'utilisation de la messagerie et l'accès aux Web ;
• Développer : contient des informations relativement précises sur le langage de commande bash (le shell de chez gnu), l'utilisation de ces étranges bêtes que sont les makefiles, et la façon de créer des programmes en langage C qui est le langage utilisé pour développer unix ;
• Se mettre à l'aise : permet de comprendre comment on peut configurer son environnement de travail : personnaliser son shell, comprendre le fonctionnement des éditeurs de texte vi et Emacs, configurer l'environnement graphique, et quelques pistes pour installer des logiciels sur son propre compte ;
• À l'aide ! donne des pistes pour chercher de la documentation sur les commandes d'unix à la fois localement et en ligne.

Il est conseillé de lire ce manuel de manière linéaire au moins une fois, pour comprendre comment s'articulent les différents concepts introduits. On pourra revenir dans un deuxième temps sur des informations plus spécifiques contenues dans certains chapitres. La complexité et l'immensité du sujet font que vous trouverez beaucoup d'interconnexions entre les sujets traités.

Avec une imprimante(7), en utilisant la version « papier » produite à partir de ce document, version prévue pour être massicotée en 15 cm par 25 cm. Au cas où vous ne disposeriez pas de massicot et souhaiteriez imprimer ce manuel sur un format A4, vous trouverez toutes les informations nécessaires sur http://lozzone.free.fr.

Nom de l'auteur : Vincent Lozano ;

Titre : Tout ce que vous avez toujours voulu savoir sur unix sans jamais avoir osé le demander ;

Date : 1^er mars 2011

Copyleft : ce manuel est libre selon les termes de la Licence Art Libre (http://www.artlibre.org) (LAL).

La LAL stipule en résumé que vous pouvez copier ce manuel. Vous pouvez également le diffuser à condition :

• d'indiquer qu'il est sous la LAL ;
• d'indiquer le nom de l'auteur de l'original : Vincent Lozano et de ceux qui auraient apporté des modifications ;
• d'indiquer que les fichiers sources peuvent être téléchargés sur http://lozzone.free.fr ;

Enfin vous pouvez le modifier à condition :

• de respecter les conditions de diffusion énoncées ci-dessus ;
• d'indiquer qu'il s'agit d'une version modifiée et si possible la nature de la modification ;
• de diffuser vos modifications sous la même licence ou sous une licence compatible.

Certaines conventions utilisées dans ce manuel nécessitent d'être quelque peu éclaircies. Les commandes unix qui parsèment le document apparaîtront comme ceci :

$ type cat
cat is /bin/cat
$

Certaines parties sont présentées sous forme de « notes » pour éclaircir un point sans que la lecture soit indispensable au premier abord.

Si la lecture est indispensable, on aura recours au pictogramme ci-contre pour attirer l'attention du lecteur distrait…

Les logiciels sont typographiés comme indiqué ci-avant. Les mots en anglais sont produits like this. Pour mettre en évidence les parties génériques d'une commande, on utilisera cette notation. Par exemple, on pourra trouver une phrase comme :

• « …pour obtenir des informations sur les attributs d'un fichier dont le nom est nomfic

  • $ ls -l nomfic

  et le tour est joué … »

Dans la version papier apparaissent des renvois sur des chapitres ou des paragraphes, comme celui-ci dirigeant le lecteur vers la gestion des processus sous unixProcessus.

À l'équipe de recherche de feu l'IUP Vision de Saint-Étienne pour m'avoir soutenu dans ce travail, plus particulièrement à Serge Chastel qui a rédigé la première version du chapitre « À l'aide ». À Jacques Lopez pour avoir pu relire attentivement ce manuel et me proposer des suggestions constructives. À Laurent Defours pour insister à me faire utiliser des mots du français. J'ai dû sous la pression faire :

for F in *.tex ; do
  sed 's/librairie/bibliothèque/g' $F |
  sed 's/Librairie/Bibliothèque/g' > tmp.tex ;
  mv -f tmp.tex $F ;
done

pour rendre ce document acceptable à ses yeux(8). À Nabil Boukala pour avoir trouvé exactement 138 coquilles et autres fautes dans la précédente version, ainsi que pour m'avoir indiqué l'orthographe exacte de « Massachusetts ». Aux intervenants des newsgroups autour de LINUX et d'unix pour leurs précieuses informations qu'ils m'ont indirectement apportées. À Andrea Ferraris pour ses encouragements, à Cédric « rixed » pour ses remarques sur l'Osf, Hugues « débianiste avant tout » pour sa précision sur la naissance du projet gnu, Jacques L'Helgoualc'h pour m'avoir suggéré qu'un mécano réparait des voitures et qu'un meccano était un jeu de construction, Paul Gaborit pour sa remarque judicieuse sur le caractère libre du package french de LATEX, un grand merci à Géo « cherchetout » pour m'avoir transmis 149 coquilles après avoir lu le document intégrant les 138 fautes repérées par Nabil.

J'adresse mes plus profonds remerciements à Stéphane Chazelas pour sa lecture minutieuse de la version précédente de ce manuel. C'est suite à ses remarques constructives que ce manuel s'est enrichi de nombreuses « nota » et surtout que beaucoup d'imprécisions et d'erreurs de fond ont été corrigées…

Je tiens enfin à exprimer ma gratitude et mon grand respect pour le travail et la motivation d'Alexis Kaufman et Didier Roche qui m'ont fait confiance pour la publication de ce livre. Merci également à tous les membres du groupe de relecture des Framaboooks pour l'effort qu'ils ont fourni pour parfaire ce document : en particulier Barbara « Garburst » que l'on peut qualifier d'« œil de lynx », Laurent « lolonene », kinouchou. Un autre merci va à Philippe Martin qui m'a transmis des fichiers « diff » permettant de corriger 51 coquilles directement sur les sources LATEX.

Enfin, je souhaite remercier chaleureusement Christophe Masutti pour sa lecture attentive. Je pense qu'une bonne trentaine de virgules ainsi que bonne vingtaine d'appels de notes de bas de page ont été correctement placés grâce à lui.

À toute la communauté des hackers pour l'énergie qu'ils insufflent…