Dans cette troisième partie, nous allons tenter d'y voir plus clair sur le fond, avant d'aborder une quatrième partie, puis peut-être une cinquième... Quelques explications de fond (peut-être exprimées maladroitement, vous me le pardonnerez) permettront sans doute de mieux comprendre les principes généraux. Dans cette partie, on fera moins de manipulations.

Le Terminal et le shell

Même si nous continuerons à utiliser la notion de "manipulation sous le Terminal", il faut savoir que le Terminal, en réalité, n'est lui-même qu'un GUI, en quelque sorte, c'est-à-dire une interface qui lance un shell. Le shell est la véritable interface entre l'utilisateur et le système. Le Terminal sert juste à ouvrir le shell dans des fenêtres et à offrir quelques préférences pour le confort de l'utilisateur.

Le Terminal n'est une application que sous OS X ou sous diverses interfaces graphiques utilisées avec Unix (XWindows, Gnome, etc.). Au départ, le Terminal est un poste avec un clavier et un écran qui n'affiche que le shell, et ce poste est relié à un ou plusieurs serveurs Unix qui renferment, eux, le système et les exécutables. En d'autres termes, il s'agit d'un périphérique.

Le terme "émulateur de Terminal" serait plus précis mais on dira "Terminal" par commodité. Cette notion de Terminal en version logicielle n'est plus un périphérique, bien sûr, mais une interface. L'émulation de Terminal est utilisée depuis longtemps, même sans Unix. Les plus anciens se souviendront de la connexion avec des serveurs BBS en RTC, sans interfaces particulières comme FirstClass ou TeleFinder. Si la connexion BBS en mode texte a été peu utilisée sur Mac (sauf par les connaisseurs), elle était très courante sur Atari, PC, Amiga ou autres...

C'est même avec ce type de Terminal que l'on pouvait vérifier la chaîne d'initialisation du modem, sa connexion à la machine, diverses commandes AT, etc. Il n'y a pas de différence fondamentale entre certaines commandes AT envoyées au modem et certains exécutables Unix. Le principe est à peu près le même, tout en conservant leurs champs d'action spécifiques.

Ces explications n'étaient pas indispensables à 100 %, mais elles restent utiles pour comprendre ces notions de terminal, shell, commandes...

Applications Mac OS et exécutables Unix

Il ne faut pas confondre une application Mac OS X qui est en fait, dans le cas d'une application Cocoa, un dossier (progiciel) avec l'extension .app (même si cette extension est masquée). En ce qui concerne les applications Carbon, certaines se présentent sous forme de de dossiers progiciels, d'autres sous la forme classique d'applications. Dans tous les cas, l'OS et le Finder les considèrent comme des applications qui peuvent être lancées normalement, par un double clic ou en glissant un fichier sur leur icône.

Les exécutables Unix ne pourront pas être lancés par un double clic sous le Finder. Ils ne peuvent être actionnés que depuis le Terminal ou une application dite GUI.

Shell ou GUI ?

N'oublions pas que, si un utilitaire comme batCHmod est un GUI pour divers exécutables concernant les droits, savoir manipuler le Terminal est parfois plus direct et plus efficace quand se pose un problème de droits dans l'urgence et si on n'a pas batCHmod sous la main...

S'il n'est pas obligatoire d'apprendre par coeur le fonctionnement du système que l'on utilise, il est certain que, plus on le connaît, plus on règle des situations avec aisance. Et c'était déjà vrai sous Mac OS classique : celui qui se donnait la peine de se familiariser avec le contenu du dossier Système était plus à l'aise pour débrouiller des conflits d'extensions.

En gros, il ne s'agit pas de choisir entre shell ou GUI, et surtout pas d'en faire une question affective ou de principe. Ce serait une grosse erreur. Il faut savoir quand l'un est plus approprié que l'autre. Il y a des cas où on peut choisir le confort, le GUI permettra, en quelques clics, de réaliser certaines opérations. Et d'autres cas où l'urgence ne laisse pas le loisir d'utiliser, ni même de télécharger, l'utilitaire adéquat. Bien sûr, ces urgences sont très rares mais, vous le savez bien, c'est toujours au mauvais moment... Et, aussi rares soient-elles, quand elles arrivent, il est peu probable qu'on se console avec des statistiques...

Ce qui signifie que, dans tous les cas, on choisit son environnement, ses utilitaires favoris, mais on a tout intérêt à savoir faire les choses soi-même, donc de se familiariser un minimum avec le shell et ses commandes. Si, un jour, il n'y a pas d'autre solution que de démarrer en mode single user, on sera bien face à un shell, et ce qu'on aura appris (ou pas appris) sur les commandes fera la différence...

C'est un peu comme sous Mac OS classique : nous utilisons le plus souvent le Gestionnaire d'Extensions ou Conflict Catcher, même pour résoudre des conflits importants. Mais, le jour où nous ne parvenons pas à démarrer notre Mac autrement que via un CD bootable, nous sommes bien contents si nous sommes capables de naviguer dans le dossier Système qui pose problème pour désactiver une extension, une police ou un Tableau de Bord par simple déplacement dans un autre dossier.

Alors méfions nous de cette argumentation qui laisse Unix aux snobs et qui nous fait préférer l'utilitaire qui fait tout, politiquement correct car dans l'esprit de Mac OS. Cette approche est aussi obscurantiste que celle qui consiste à dire "hors du shell point de salut".

Si cette argumentation vous a convaincu, vous pouvez aisément en savoir plus sur la plupart des commandes d'Unix.

Comment trouve-t-on les commandes ?

La commande man, comme nous l'avons vu, permet de lire une documentation sur les commandes Unix. Mais, si cette commande ne nécessite pas d'autre argument que le nom de la commande sur laquelle on veut se documenter, encore faut-il connaître ce nom.

Les commandes Unix sont normalement rangées dans deux dossiers, eux-mêmes rangés dans le dossier usr. le dossier bin contient les commandes accessibles aux utilisateurs, tandis que le dossier adm contient les commandes réservées à l'administrateur.

Sous Mac OS X, le rangement est un peu différent, tout en respectant le même principe. Il y a quatre dossiers. Deux se trouvent à la racine et sont nommés bin et sbin. Le nom sbin évoque les exécutables attachés à l'administrateur (superuser). Dans le dossier usr se trouvent également un dossier bin et un dossier sbin, le second rassemblant plutôt les commandes d'administrateurs.

Pourquoi cette classification en quatre dossiers plutôt que deux ? J'avoue que je ne prétends pas avoir une réponse sûre, mais une hypothèse me paraît très probable.

En effet, Mac OS X peut être lancé suivant deux modes, le mode normal de niveau 1 (multi-utilisateurs) qui charge toutes les couches, dont Aqua (c'est le Mac OS X que nous utilisons tous les jours), ainsi que les services, et le mode single user de niveau 0 (démarrage avec S enfoncé) pour une maintenance.

Quand on démarre sous le deuxième mode, seul un shell est chargé (sans l'interface du Terminal) et il est probable que les dossiers bin et sbin situés à la racine contiennent toutes les commandes pour accéder à la maintenance du système à ce stade de démarrage. Alors que les dossiers bin et sbin contenus dans le dossier usr contiennent plutôt les exécutables d'utilisation courante via le Terminal ou un GUI.

Cette explication n'est pas certaine, mais c'est celle qui me semble la plus logique aujourd'hui.

Donc, maintenant que vous savez que les exécutables Unix se trouvent dans ces quatre dossiers, rien de plus simple que de les visiter (vous devez savoir comment, maintenant). Une fois listés les exécutables présents, rien de plus simple que de lancer des commandes man pour ceux qui vous intéressent.

Et, si vous êtes certains d'avoir compris le principe de la commande man, vous allez maintenant pouvoir vous en servir de façon plus confortable.

Récréation

Logiquement, naviguer dans le Terminal devrait vous être plus familier, à défaut de vous être plus sympathique. Il est donc temps de vous signaler l'existence d'un GUI qui va vous rendre de grands services. Vous avez remarqué qu'exécuter des commandes man et apropos entraîne une arrivée massive de texte dans vos fenêtres de Terminal, et il devient de plus en plus difficile de tout lire tout en continuant à y voir clair dans vos commandes et leurs résultats.

Les plus malins d'entre vous auront déjà ouvert une seconde fenêtre de Terminal, et réservé leurs essais à une fenêtre trandis que l'autre reçoit les commandes man, whatis et apropos...

Vous pouvez aussi installer ManOpen, qui va se charger d'ouvrir les fichiers man de façon plus agréable.

ManOpen

Vous trouverez ManOpen sur le site de Carl Lindberg, son auteur.

L'application (ManOpen) pourra être copiée n'importe où, mais vous devrez passer en root (soit avec une nouvelle session, soit en effectuant les opérations sous le Terminal si vous savez le faire) pour copier openman dans le dossier /usr/bin et la documentation openman.1 dans le dossier /usr/share/man/man1 (sous Jaguar vous pourrez aisément modifier temporairement les droits de ces dossiers le temps d'y glisser les fichiers).

L'application ManOpen permet d'ouvrir des fichiers man ou de faire des recherches apropos. Un bon utilitaire, donc.

Le rôle d'openman est simple. Si vous utilisez la commande openman cd plutôt que man cd, l'application ManOpen sera lancée et vous permettra de consulter le fichier man dans de meilleures conditions. Quant au fichier openman.1, c'est tout simplement la documentation d'openman, et il s'ouvre avecla commande man openman ou, mieux et vous l'avez normalement deviné, parla commande openman openman qui demande à ManOpen d'ouvrir la doc d'openman.

Bien entendu, vous pouvez aussi lancer l'application ManOpen depuis le Finder, comme n'importe quelle application, et utiliser ses menus pour ouvrir des documentations.