Editions ENI Livres | Vidéos | e-Formations
Éditeurs de texte
Pourquoi parler d’éditeurs de texte ?
Un shell script, c’est un fichier texte brut. Plus précisément, c’est une retranscription dans un fichier de ce que l’on taperait directement dans un shell. Par conséquent, il est nécessaire de connaître au moins un éditeur de texte afin de pouvoir écrire des shell scripts. Il existe de très nombreux éditeurs de texte, certains étant dédiés à certaines tâches et certains étant généralistes.
Précision importante : on parle ici d’éditeurs de texte, pas de traitement de texte. Il faut oublier Microsoft Word, OpenOffice, LibreOffice et tous les logiciels de ce type : l’objectif avec ces logiciels est la mise en page, ce qui est totalement incompatible avec les scripts. Bien sûr, il est tout à fait possible de sauvegarder des fichiers en texte brut à partir d’un traitement de texte, mais son interface est totalement inadaptée.
Caractères de contrôle et CRLF
Les systèmes d’exploitation que vous utilisez s’appuient tous sur le codage ASCII des caractères, norme définie dans les années 60. Ce codage définit 128 codes à 7 bits, chacun de ces codes représentant un caractère, imprimable ou non.
Différentes normes (appelées « ASCII...
Console ou interface graphique
Des éditeurs de texte, il en existe des centaines, avec des fonctionnements différents, des interfaces différentes, des logiques différentes, des objectifs différents... Mais un aspect important à partir duquel on peut séparer les éditeurs en deux grandes catégories, c’est la nature de son interface : en mode texte (console) ou en interface graphique.
Bien souvent, on a naturellement une préférence pour l’interface graphique, car on est habitué à utiliser des logiciels graphiques. Cependant, l’écriture de scripts est une activité particulière en cela qu’elle se fait souvent « à petite échelle » et directement sur les serveurs concernés. Et un serveur, ça n’a pas d’interface graphique.
Dans ce cas, on a deux possibilités principales :
-
Soit on édite un script localement sur son poste de travail, pour le téléverser sur le serveur cible et l’exécuter, sans oublier d’effectuer des tests (ce qui aboutit souvent à plusieurs dizaines de téléversements pour le même fichier).
-
Soit on édite le script directement sur le serveur, souvent à travers une connexion distante SSH, avec un éditeur de texte en console.
On a en réalité d’autres...
Quels éditeurs ?
Il n’est pas possible de faire la liste de tous les éditeurs de textes disponibles : ceux-ci sont bien trop nombreux, on les compte par centaines. Cette section tente toutefois de lister les plus importants d’entre eux, vous permettant de faire un choix éclairé parmi une collection d’outils, afin d’en choisir un pour ce rôle central dans cette activité professionnelle. Tous répondent au besoin exprimé (écrire des scripts shell) sans difficulté, chacun apportant une approche différente ou un environnement de travail particulier.
1. Les ancêtres
Dans les années 1960, l’informatique ne ressemblait pas à ce que l’on connaît aujourd’hui. Trois points en particulier concernent le fonctionnement des éditeurs de texte :
-
Les modems étaient particulièrement lents : 30 à 120 octets par seconde, soit jusqu’à 1 minute pour transférer l’équivalent d’un écran texte de 80×24 caractères.
-
La mémoire était limitée et précieuse, il fallait éviter d’y charger des informations qui n’étaient pas impérativement nécessaires.
-
L’« affichage » ne se faisait pas sur des écrans, mais sur des téléscripteurs, appareils ressemblant à des machines à écrire, où le papier fait...
Vim : performant, léger et universel
Pour différentes raisons, il est préférable de savoir utiliser Vim :
-
Les standards POSIX garantissent la présence de vi dans le système : vous retrouverez un éditeur de cette famille sur quasiment tous les systèmes de type UNIX que vous rencontrerez.
-
Cet éditeur est très léger, très rapide et très réactif : à partir du moment où l’on connaît les bases de son utilisation, il permet d’être très efficace.
-
Même avec des gros fichiers, Vim reste réactif (là où certains éditeurs peuvent bloquer en essayant d’en charger le contenu).
-
Initialement écrit pour des interfaces textuelles, il existe en version graphique (GVim, MacVim) et même sans cela, certaines actions à la souris sont possibles en « mode console », même au travers d’une connexion SSH.
Bon nombre d’aficionados d’Emacs ont d’ailleurs appris les rudiments de vi pour éditer des fichiers sur des serveurs distants en s’affranchissant de la lourdeur du lancement de leur éditeur préféré (celui-ci s’est toutefois amélioré sur ce point ces dernières années).
Ce chapitre détaille donc l’utilisation de Vim, cela ne signifie en aucun cas que ce logiciel est mieux qu’un autre, en particulier Emacs. Il s’agit simplement d’un choix de raison, la maîtrise de ce logiciel offrant plus de possibilités grâce au standard POSIX qui garantit la présence d’une variante de vi. Avouons-le aussi : c’est l’éditeur de prédilection de l’auteur de cet ouvrage !
Attention, ce chapitre ne survole que les bases de l’utilisation de Vim : si vous voulez devenir un expert de cet éditeur, il faudra vous tourner vers d’autres ouvrages. C’est même fortement conseillé !
Vous remarquerez ultérieurement que certaines commandes de vi s’utilisent de la même manière que d’autres commandes UNIX : lors de leurs créations, les différentes commandes se sont inspirées les unes des autres.
1. Un peu d’histoire
Dans les années 1960, les performances...
Nano : léger et simple
Si toutefois vous préférez n’utiliser à distance qu’un éditeur simple, en écrivant peut-être la majorité de vos scripts avec votre éditeur de prédilection, que vous avez déjà passé du temps à apprendre, vous pouvez vous contenter de Nano pour éditer localement certains scripts qui n’auraient besoin que de légères modifications.
Nano est un éditeur simple à utiliser, similaire à la plupart des éditeurs que l’on peut connaître : une fois un fichier ouvert, on peut directement l’éditer, il n’y a pas de fonctionnement modal comme Vim, ni d’interface particulière. En cela, il est particulièrement facile à appréhender.
Lorsque l’on souhaite simplement éditer rapidement un fichier, cet éditeur est relativement pratique et facile à utiliser. Cependant, même s’il a certaines fonctionnalités avancées, il ne permet pas d’écrire aussi efficacement que d’autres éditeurs des longs documents : il serait illusoire d’imaginer n’utiliser exclusivement que cet éditeur.
1. Origine et histoire
Nano (dont le développement a commencé en 1999) est un clone d’un autre éditeur nommé Pico (apparu en 1989), la licence de ce dernier n’étant pas considérée comme libre selon les règles établies par le projet Debian.
À l’origine développé de manière indépendante, ce projet a rapidement (2001) rejoint le projet GNU, soutenu par la Free Software...
Accès distant
Lorsque vous souhaitez travailler avec un éditeur local à votre poste de travail pour modifier des scripts distants, le plus pratique est de monter l’arborescente distante en utilisant le protocole SSH (plus précisément, son sous-protocole SFTP) : à partir du moment où vous avez un accès à un shell au travers du protocole SSH pour exécuter des commandes sur un serveur.
Sous Linux
Les gestionnaires de fichiers des environnements de bureau majeurs sous Linux (notamment GNOME et KDE) supportent par défaut le protocole SSH : il suffit généralement d’indiquer « ssh://adresse_du_serveur/ » dans la barre d’adresse pour utiliser un système de fichiers distant comme s’il était local. Lorsque l’on n’utilise pas de tel gestionnaire de fichiers, l’outil SSHFS (pour SSHFile System) permet de monter une arborescence distante utilisable par n’importe quel programme…
Sous Windows
Les utilisateurs de Windows peuvent se servir de WinSCP (https://winscp.net/) ou FileZilla (https://filezilla-project.org/) pour accéder à l’arborescence distante, mais cela ne donne pas un accès direct à ces fichiers. Pour répondre à cette problématique, il est possible d’installer Swish (http://www.swish-sftp.org/), qui ajoute le support de SSH à...
