<!doctype linuxdoc system>
  <article>
      <title>Man page HOWTO</title>
      <author>
          Auteur : Jens Schweikhardt <htmlurl url="mailto:schweikh@noc.dfn.de" 
                                              name="schweikh@noc.dfn.de">
          <newline>
          <htmlurl url="http://www.shuttle.de/schweikh/home.html" 
                   name="www.shuttle.de/schweikh/home.html">
      </author>
      <date>
        Mars 1998
      </date>

      <abstract>
        (Adaptation française par Alexandre Devaure <htmlurl
        url="mailto:adevaure@mail.dotcom.fr"
        name="adevaure@mail.dotcom.fr">, 2 juin 1999).
        Ce HOWTO explique ce que vous devrez avoir en tête quand vous
        prévoyez d'écrire une documentation en ligne (plus connue sous le nom de
        page de manuel) que vous voulez rendre accessible via la
        commande <tt>man(1)</tt>. Tout au long de ce HOWTO, une entrée
        du manuel sera simplement appelée page de manuel,
        quelque soit sa longueur réelle et sans intention sexiste.
      </abstract>
    <toc>
    <sect>Quelques évidences à propos de la documentation
      <p>
        Pourquoi écrivons-nous une documentation&nbsp;? C'est une
        question bête. Parce que nous voulons que d'autres personnes
        puissent utiliser notre programme, notre fonction dans une librairie
        ou quoi que ce soit que nous avons écrit et rendu disponible. Mais
        écrire une documentation n'est pas suffisant&nbsp;:
        <itemize>
          <item>
            la documentation doit être accessible. Si elle est cachée à
            un endroit non standard où les outils de recherche relatifs à la
            documentation ne la trouveront pas, comment peut-elle
            remplir son rôle&nbsp;?
          <item>
            la documentation doit être fiable et précise. Il n'y a rien de
            plus irritant qu'un programme se comportant différemment
            de ce qui est écrit dans sa documentation. Les
            utilisateurs vous maudiront, vous enverront des courriers
            d'insulte, puis rejetteront à jamais tout autre travail
            venant de vous.
        </itemize>
        La méthode traditionnelle pour accéder à la documentation sous
        UNIX fait appel à la commande <tt>man(1)</tt>. Ce HOWTO décrit
        ce que vous devez faire pour écrire une page de manuel qui
        sera correctement traitée par les outils prévus à cet effet,
        dont les plus importants sont <tt>man(1)</tt>, <tt>xman(1x)</tt>,
        <tt>apropos(1)</tt>, <tt>makewhatis(8)</tt> et
        <tt>catman(8)</tt>.
      </p>
      <p>
        La qualité et la véracité des informations sont, bien sûr, de votre
        ressort. Malgré tout, vous trouverez dans ce guide quelques idées qui
        vous permettront d'éviter certains pièges courants.
      </p>
    </sect>

    <sect>Comment accède-t-on aux pages de manuel ?
      <p>
        Vous devez connaître avec précision le mécanisme d'accès aux pages de
        manuel afin de savoir donner un nom correct à vos documents, et d'être
        capable de les installer au bon endroit. Chaque page de manuel
        appartient à une section spécifique, dénotée par un simple chiffre.
        Les sections les plus courantes rencontrées sous Linux sont :
        <itemize>
          <item> 1 : commandes utilisateurs pouvant être exécutées par
          tout le monde&nbsp;;
          <item> 2 : appels systèmes, c'est-à-dire les fonctions
          fournies par le noyau&nbsp;;
          <item> 3 : fonctions des bibliothèques&nbsp;;
          <item> 4 : périphériques, c'est-à-dire les fichiers spéciaux
          que l'on trouve dans le répertoire <tt>/dev</tt>&nbsp;;
          <item> 5 : descriptions des formats de fichiers (comme par exemple
            <tt>/etc/passwd</tt>&nbsp;;
          <item> 6 : les jeux, sans commentaire...
          <item> 7 : divers (macros, conventions particulières, ...)&nbsp;;
          <item> 8 : outils d'administration exécutables uniquement
          par le super utilisateur&nbsp;;
          <item> 9 : un autre endroit (spécifique à Linux) destiné à la
            documentation des services offerts par le noyau&nbsp;;
          <item> n : nouvelle documentation, qui pourra être déplacée vers un
            endroit approprié&nbsp;;
          <item> o : ancienne documentation, qui peut être conservée encore un
            certain temps&nbsp;;
          <item> l : documentation locale, propre à ce système particulier.
        </itemize>
        Le nom du fichier source d'une page de manuel (le fichier d'entrée du
        système de formatage) est le nom de la commande décrite (ou de la
        fonction, du fichier, etc.), suivi d'un point et du numéro de section.
        Si, par exemple, vous documentez le format du fichier
        "<it>passwd</it>", vous devez appeler le fichier source
        "<it>passwd.5</it>". Nous avons ici un exemple d'un fichier
        qui porte le  même nom qu'une commande&nbsp;; nous aurions tout
        aussi bien avoir une fonction de bibliothèque appelée
        "<it>passwd</it>". L'organisation en sections constitue la
        méthode habituelle pour résoudre ces ambiguïtés : la
        description de la commande se trouvera dans le fichier
        "<it>passwd.1</it>" et notre hypothétique fonction de
        bibliothèque dans "<it>passwd.3</it>".
      </p>
      <p>
        Quelquefois, une lettre est ajoutée au numéro de section comme
        par exemple "<it>xterm.1x</it>" ou "<it>wish.1tk</it>". Le but
        de cette notation est d'indiquer qu'il s'agit respectivement
        d'une documentation d'un programme  X Window ou d'une
        application Tk. Certains programmes d'affichage du manuel
        peuvent exploiter cette particularité ; <tt>xman</tt>, par
        exemple affichera "<it>xterm(x)</it>" et "<it>wish(tk)</it>"
        dans la liste des documents disponibles.
      </p>
      <p>
        S'il vous plaît, n'utilisez pas les sections n, o et l&nbsp;: selon le
        standard du système de fichiers (File System Standard), ces sections
        sont déconseillées, utilisez plutôt les sections numériques.
      </p>
      <p>Attention aux éventuels conflits de noms avec des programmes,
        fonctions ou fichiers déjà existants. Ce serait certainement une
        mauvaise idée d'écrire un autre éditeur de texte et de le nommer ed,
        sed (pour super ed) ou red (pour Roger edition). En vous assurant
        que le nom de votre programme est unique, vous éviterez que
        quelqu'un exécute votre programme et qu'il lise la page de manuel
        d'un autre ou <it>vice verca</it>. Vous pouvez éventuellement vous
        aider de la base de données "lsm" qui recense beaucoup de
        programmes disponibles pour Linux.
      </p>
      <p>
        Maintenant que nous savons quel nom donner à notre fichier, la
        prochaine décision est de choisir le répertoire dans lequel nous
        l'installerons (quand l'utilisateur lancera la commande "make
        install"). Sous Linux, toutes les pages de manuel sont dans des
        sous-répertoires à partir d'une racine mémorisée dans la variable
        d'environnement MANPATH. Les outils de traitement de la
        documentation l'utilisent de la même manière que le shell utilise
        la variable PATH pour trouver les exécutables. En fait, MANPATH a
        le même format que PATH : toutes les deux sont une liste de
        répertoires séparés par des ":" (mais MANPATH n'autorise pas de
        champs vides ou des chemins relatifs, seulement des chemins
        absolus). Si MANPATH n'existe pas ou si elle n'est pas exportée,
        /usr/man est utilisée comme valeur par défaut. Dans le but
        d'accélerer la recherche et pour garder les répertoires de taille
        raisonable, les répertoires pointés dans MANPATH (aussi appelés
        répertoires de base) contiennent une multitude de sous-répertoires
        nommés "<it>man&lt;s&gt;</it>" où &lt;s&gt; désigne le caractère
        correspondant à la section présenté plus haut. Toutes les sections
        ne sont pas représentées, il n'y a pas, par exemple de raison de
        garder une entrée "<it>mano</it>". Vous pourrez y trouver également
        des sous-répertoires appelés "<it>cat&lt;s&gt;</it>",
        "<it>dvi&lt;s&gt;</it>" et "<it>ps&lt;s&gt;</it>", qui contiennent
        toute la documentation formatée, prête à être affichée ou
        imprimée&nbsp;: nous reviendrons sur ce sujet plus loin. Le
        seul fichier à être présent à côté de ces sous-répertoires du
        répertoire de base s'appelle "<it>whatis</it>". Le but et la
        création de ce fichier sera décrit dans la section 11. La
        méthode la plus sûre pour installer au bon endroit une page de
        manuel de la section "s" est de mettre le fichier dans le répertoire
        "<it>/usr/man/man&lt;s&gt;</it>". Toutefois, un bon
        <tt>Makefile</tt> devra autoriser l'utilisateur de choisir un autre
        répertoire de base, disons par exemple par le biais d'une variable
        d'environnement que l'on pourrait nommer MANDIR. La plupart des
        distributions GNU peuvent être configurées à l'aide de l'option
        <tt>--prefix=/nom/option</tt>. Les pages de manuels correspondantes
        seront alors installées à partir du répertoire de base
        <it>/mon/option/man</it>. Je vous suggère d'utiliser une méthode
        similaire pour vos réalisations personnelles.
      </p>
      <p>
        Depuis l'avènement du "<it>Système de fichiers standard</it>" pour
        Linux (FS-STnd), les choses se sont compliquées. Le FS-STnd 1.2 stipule
        que&nbsp;:
        <quote>
          des aménagements doivent être faits dans la structure de
          <it>/usr/man</it> pour supporter des pages de manuel écrites dans
          différentes (ou mutiples) langues.
        </quote>
      </p>
      <p>
        Ceci est fait en introduisant un niveau de
        répertoires supplémentaire qui distingue les différentes
        langues. Citant encore le FS-Stnd 1.2&nbsp;:
        <quote>
          Le nommage des sous-répertoires correspondants aux langues
          de <it>/usr/man</it> est basé sur l'appendice E du standard POSIX
          1003.1 qui décrit la chaîne de caractères
          d'authentification <it>locale</it> (qui est la méthode la
          mieux acceptée pour décrire un environement culturel). La
          chaîne <it>locale</it> se présente sous la forme
          <verb>
            &lt;langage&gt;[_&lt;pays&gt;][.&lt;jeu-de-caracteres&gt;][,&lt;version&gt;]
          </verb>
        </quote>
        (Reportez vous au FS-Stnd pour voir quelques chaînes
        <it>locale</it>courantes.) D'après ces recommandations, nous
        avons nos pages de manuel dans
        <it>/usr/man/&lt;locale&gt;/man[1-9lno]</it>. Les versions
        formatées se trouveraient alors bien entendu dans
        <it>/usr/man/&lt;locale&gt;/cat[1-9lno]</it>&nbsp;: nous
        pourrions ne les fournir que pour une seule langue.
      </p>
      <p>
        TOUTEFOIS, je (l'auteur du document, pas le traducteur) ne
        peut pas recommander de passer a cette structure en l'état
        actuel des choses. Le FS-Stnd 1.2 autorise aussi que
        <quote>
          les systèmes qui n'utilisent qu'une seule langue et jeu de
          caractères pour toutes les pages de manuel peuvent omettre
          la sous-chaîne <it>&lt;locale&gt;</it> et stocker toutes ces
          pages dans le répertoire <it>mandir</it>. Par exemple, les
          machines équipées seulement de pages de manuel en anglais
          codées en ASCII peuvent mettre les pages de manuel (les
          répertoires <it>man[1-9]</it>) directement dans
          <it>/usr/man/</it>. Il s'agit en fait de l'arrangement
          habituel.
        </quote>
      <p>
        Je (l'auteur du document, pas le traducteur) ne changerai pas
        ma configuration tant que tous les outils (comme
        <tt>xman</tt>, <tt>info</tt>, <tt>tkman</tt> et beaucoup
        d'autres) ne seront pas tous adaptés à cette nouvelle
        structure.
      </p>
    </sect>
    <sect>A quoi ressemble une page de manuel formatée&nbsp;?
      <p>
        Laissez-moi vous présenter un exemple que j'expliquerai plus tard. En
        raison de la nature et du mode de réalisation de ce document, nous ne
        pouvons pas reproduire les caractères accentués, ni les différents
        enrichissements du texte (gras et italiques principalement)&nbsp;;
        consultez la section traitant des polices de caractères pour obtenir
        des détails sur ces possibilités.
      </p>
      <p>Voici comment se présente la page de manuel de notre programme
        hyphothétique "<tt>prout</tt>"&nbsp;:

        <verb>


      PROUT(1)                Manuel utilisateur               PROUT(1)


      NAME
             prout - proutibule la bibliotheque plaf

      SYNOPSIS
             prout [-plaf] [-c fichier-config ] fichier ...

      DESCRIPTION
             prout  proutibule  la  bibliotheque plaf en mouglifiant la
             table des symboles.  Par  defaut,  la  commande  recherche
             tous  les segments glurb et les trie par ordre betagonique
             decroissant afin que  le  gloupeur  gloup(1)  les  trouve.
             L'entree  symdef  est  alors  compactee selon l'algorithme
             NABOB.   Les  fichiers  sont  traites  dans   leur   ordre
             d'apparition sur la ligne de commandes.

      OPTIONS
             -b     N'affiche  pas  `bidouille  en cours' sur la sortie
                    standard pendant le traitement.

             -c fichier-config
                    Utilise le fichier de configuration  fichier-config
                    au  lieu  du  fichier global /etc/prout.conf.  Cela
                    supprime   aussi    l'effet    de    la    variable
                    d'environnement PROUTCONF.

             -a     Traite  egalement  les  en-tetes froutz en plus des
                    segments glurb.

             -r     Mode  recursif.  Fonctionne  a  la  vitesse  de  la
                    lumiere,  mais  necessite  plusieurs  megaoctets de
                    memoire virtuelle.

      FICHIERS
             /etc/prout.conf
                    Fichier de  configuration  general,  pour  tout  le
                    systeme. Voir prout(5) pour plus de details.
             ~/.proutrc
                    Fichier  de  configuration propre a chaque utilisa
                    teur. Voir prout(5) pour plus de details. 

      ENVIRONNEMENT
             PROUTCONF
                    Si elle existe, cette  variable  peut  contenir  le
                    chemin  d'acces  complet a un autre fichier de con
                    figuration global  prout.conf.   L'option  -c  rend
                    cette variable inoperante.

      DIAGNOSTICS
             Les  messages suivants peuvent etre affiches sur la sortie
             standard d'erreurs :

             Mauvais nombre magique.
                    Le fichier d'entree ne semble pas etre  un  fichier
                    archive.

             Segments glurb ancien style.
                    prout  ne peut traiter que le nouveau style de seg
                    ments glurb. Les bibliotheques GROBOL ne  sont  pas
                    supportees dans cette version.

      BOGUES
             Le  nom de cette commande aurait du etre choisi de maniere
             a mieux refleter sa fonction.

      AUTEUR
             Marcel Dugenou    <dugenou@renux.freenix.fr>

      VOIR AUSSI
             gloup(1), plaf(1), prout(5).

      Linux                      JANVIER 1996                         1
        </verb>
      </p>
      <p>Et voici les explications promises&nbsp;:
        <descrip>
          <tag>La section NAME&nbsp;:</tag> C'est la seule section requise.
            Les pages de manuel sans une section "NAME" sont aussi
            utiles que des réfrigerateurs au Pôle Nord. Cette section a
            aussi un format standardisé constitué d'une liste de
            programmes ou noms de fonctions séparés par des virgules
            suivie d'un tiret et d'une courte description
            (habituellement une ligne) de la fonctionnalité que le
            programme (fonction ou fichier) est supposé dispenser. A
            l'aide de <tt>makewhatis(8)</tt> les sections NAME sont
            incluses dans les fichiers de la base de données de
            <tt>whatis</tt>. <tt>makewhatis</tt> est la raison pour
            laquelle la section NAME doit exister et pourquoi elle doit
            adhérer au format que j'ai décrit. Dans le source groff,
            elle doit ressembler à&nbsp;: 
            <tscreen>
              .SH NAME prout \- proutibule de la bibliotheque plaf
            </tscreen>
            Le <tt>\-</tt> est important ici&nbsp;: le backslash sert a
            faire la différence entre le tiret et une marque de césure
            qui peut apparaître à l'intérieur du nom de la commande ou
            dans la ligne de description.
          </p>
          <p><bf>Attention</bf>&nbsp;: en l'état actuel des choses, vous ne
            pouvez pas  traduire NAME par NOM en français, à moins de
            modifier la plupart des programmes <tt>makewhatis</tt>
            existants. C'est bien dommage.
          </p>
          <p>
          </p>
          <tag>La section SYNOPSYS</tag>... est censée donner
            un aperçu sur les options du programme. Pour les
            fonctions, cette section fait la liste des fichiers à inclure
            et son prototype pour que le programmeur connaisse le type et le
            nombre d'arguments ainsi que le type de retour.
          <p></p>
          <tag>La section DESCRIPTION</tag> Elle explique en détail
            pourquoi votre séquence de 0 et de 1 est la meilleure de
            toutes. C'est ici que vous étalez tout votre savoir&nbsp;! Gagnez
            l'estime des autres programmeurs et des utilisateurs en
            faisant de cette section une source d'information sûre et
            détaillée.  Expliquez à quoi servent les arguments, le
            format de fichier, les algorithmes qui effectuent le plus
            dur du travail. 
          <p></p>
          <tag>La section OPTIONS</tag>Elle donne une description pour
            chaque option, comment elle affecte le fonctionnement du
            programme. Vous le saviez, n'est-ce pas&nbsp;?
          <p></p>
          <tag>La section FICHIERS</tag>Elle indique les fichiers
            utilisés par le programme ou la fonction. Par exemple, les
            fichiers de configuration, les fichiers de démarrage, les
            fichiers sur lesquels le programme agit. Ce serait une bonne
            idée de donner les chemins absolus de ces fichiers et
            d'avoir un processus d'installation qui modifie la partie
            répertoire selon les préférences de l'utilisateur&nbsp;: les
            manuels de <tt>groff</tt> ont comme préfixe par défaut
            <it>/usr/local</it>, donc ils référencent
            <it>/usrl/local/lib/groff/*</it> par défaut. Cependant, si
            vous installez en utilisant "<tt>make prefix=/opt/gnu</tt>",
            les références dans la page de manuel change en
            <it>/opt/gnu/lib/groff/*</it>.
          <p></p>
          <tag>La section ENVIRONNEMENT</tag> fait la liste de toutes les variables
            d'environnement qui affectent votre programme ou fonction
            et, bien sûr, explique
            comment. La plupart du temps, les variables
            contiendront les chemins, nom de fichiers, options par défaut.
          <p></p>
          <tag>La section DIAGNOSTIQUES</tag>Elle doit donner une vue
            d'ensemble des messages d'erreurs les plus courants de votre
            programme et des éventuelles solutions à ces problèmes. Il
            n'est pas nécessaire d'expliquer les messages d'erreurs du
            système (de <tt>perror(3)</tt>) ou des signaux fatals (de
            <tt>psignal(3)</tt>) qui peuvent apparaître pendant
            l'exécution de tout programme. 
          <p></p>
          <tag>La section BOGUES</tag> Devrait idéalement ne pas
            exister. Si vous êtes brave, vous pouvez décrire ici
            les limitations, les inconvénients, les caractéristiques
            que certains pourraient prendre pour des défauts. Si vous
            n'êtes pas brave, renommez-la en section "A FAIRE".
          <p></p>
          <tag>La section AUTEUR</tag>Il est appréciable de l'avoir
            quand il y a des erreurs grossières dans la documentation
            ou dans le comportement du programme et que vous voulez
            envoyer un rapport de bogue.
          <p></p>
          <tag>La section VOIR AUSSI</tag>C'est une liste de pages de manuel
            relatives à l'application citées par ordre alphabétique. Par
            convention, c'est la dernière section.
        </descrip>
        Vous êtes libres d'en inventer d'autres si elles n'empietent pas sur
        celles décrites au-dessus. Nous avons volontairement décrit une
        version francisée de page de manuel, puisque ce document est destiné
        aux pays francophones. Néanmoins, vous devez avoir conscience que si
        vous devez diffuser une application dans le monde entier, il vous
        faudra fournir un manuel en langue anglaise (ce qui est la version
        standard, traditionnelle), et que les noms "officiels" de ces sections
        sont en réalité, dans l'ordre : NAME, SYNOPSIS, DESCRIPTION, OPTIONS,
        FILES, ENVIRONMENT, DIAGNOSTICS, BUGS, AUTHOR et SEE ALSO.
      </p>
      <p> Donc comment générer cette page de manuel ? J'attendais cette
        question, voici le source&nbsp;:
        <verb>
 .\" Formater ce fichier par la commande :
 .\" groff -man -Tlatin1 prout.1  (si vous avez saisi des accents Iso-8859-1)
 .\" groff -man -Tascii  prout.1  (cas general )
 .\"
 .TH PROUT 1 "JANVIER 1996" Linux "Manuel utilisateur"
 .SH NAME
 prout \- proutibule la bibliotheque plaf
 .SH SYNOPSIS
 .B prout [-plaf] [-c
 .I fichier-config
 .B ]
 .I fichier
 .B ...
 .SH DESCRIPTION
 .B prout
 proutibule la bibliotheque plaf en mouglifiant la table des symboles.
 Par defaut, la commande recherche tous les segments glurb et les trie
 par ordre betagonique decroissant afin que le gloupeur 
 .BR gloup (1)
 les trouve. L'entree symdef est alors compactee selon l'algorithme NABOB.
 Les fichiers sont traites dans leur ordre d'apparition sur la ligne
 de commandes.
 .SH OPTIONS
 .IP -b
 N'affiche pas `bidouille en cours' sur la sortie standard pendant 
 le traitement.
 .IP "-c fichier-config"
 Utilise le fichier de configuration 
 .I fichier-config
 au lieu du fichier global
 .IR /etc/prout.conf .
 Cela supprime aussi l'effet de la variable d'environnement
 .B PROUTCONF.
 .IP -a
 Traite egalement les en-tetes froutz en plus des segments glurb.
 .IP -r
 Mode recursif. Fonctionne a la vitesse de la lumiere, mais necessite
 plusieurs megaoctets de memoire virtuelle.
 .SH FICHIERS
 .I /etc/prout.conf
 .RS
 Fichier de configuration general, pour tout le systeme. Voir
 .BR prout (5)
 pour plus de details.
 .RE
 .I ~/.proutrc
 .RS
 Fichier de configuration propre a chaque utilisateur. Voir
 .BR prout (5)
 pour plus de details.
 .SH ENVIRONNEMENT
 .IP PROUTCONF
 Si elle existe, cette variable peut contenir le chemin d'acces complet
 a un autre fichier de configuration global
 .IR prout.conf .
 L'option
 .B -c
 rend cette variable inoperante.
 .SH DIAGNOSTICS
 Les messages suivants peuvent etre affiches sur la sortie standard d'erreurs :
 
 Mauvais nombre magique.
 .RS
 Le fichier d'entree ne semble pas etre un fichier archive.
 .RE
 Segments glurb ancien style.
 .RS
 .B prout
 ne peut traiter que le nouveau style de segments glurb. Les bibliotheques
 GROBOL ne sont pas supportees dans cette version.
 .SH BOGUES
 Le nom de cette commande aurait du etre choisi de maniere a mieux
 refleter sa fonction.
 .SH AUTEUR
 Marcel Dugenou    &lt;dugenou@renux.freenix.fr&gt;
 .SH "VOIR AUSSI"
 .BR gloup (1),
 .BR plaf (1),
 .BR prout (5).
        </verb>
      </p>
    </sect>
    <sect>Comment documenter plusieurs choses dans une seule page de manuel&nbsp;?
      <p>
        De nombreux programmes (<tt>grep</tt>, <tt>egrep</tt>) et fonctions
        (<tt>printf</tt>, <tt>fprintf</tt>,...) sont documentées dans une
        seule page de manuel. Cependant, ces pages seraient inutilisables si
        elles n'étaient accessibles que par un seul nom. Nous ne pouvous nous
        attendre à ce qu'un utilisateur se souviennent que la page de manuel
        de <tt>egrep</tt> est en fait celle de <tt>grep</tt>. Il est par
        conséquent indispensable que la page soit accessible sous différents
        noms. Vous avez plusieurs possibilités pour y arriver&nbsp;:
        <enum>
          <item>avoir des copies identiques pour chaque nom&nbsp;;
          <item>connecter toutes les pages de manuels en utilisant des liens
            physiques&nbsp;;
          <item>utiliser les liens symboliques pointant la page de
          manuel&nbsp;;
          <item>utiliser le mécanisme de "source" de <tt>groff</tt>
          fournie par la macro "<tt>.SO</tt>".
        </enum>
        La première possibilité est une perte de place. La deuxième n'est pas
        recommandée parce que les versions intelligentes du programme
        <tt>catman</tt> peuvent gagner beaucoup de temps en regardant le type
        du fichier et son contenu. Les liens physiques réduiraient l'efficacité
        de cet outil (dont le but est de formater toutes les pages de manuel
        pour qu'elles soient affichées plus rapidement). La troisième
        alternative comporte un piège si vous êtes concerné par la
        portabilité, vous devez savoir qu'il existe des systèmes de fichiers
        qui ne supportent pas les liens symboliques. En bref,
        la Meilleure Chose (TM) est d'utiliser le mécanisme source de
        <tt>groff</tt>.
      </p>
      <p>Voila comment l'utiliser&nbsp;: si vous voulez que votre page soit
        accessible sous les noms <tt>truc</tt> et <tt>bidule</tt> dans la
        section 1, alors mettez la page de manuel dans <tt>truc.1</tt> et
        réalisez le fichier <tt>bidule.1</tt> contenant&nbsp;:
        <tscreen>
          <verb>
    .SO man1/truc.1
          </verb>
        </tscreen>
        Il est important de spécifier le répertoire <it>man1/</it> aussi bien
        que le nom du fichier <tt>truc.1</tt> car lors de l'exécution de
        <tt>groff</tt>, celui-ci aura comme répertoire courant le
        répertoire de base des pages de manuel, et il interprètera les
        arguments de <tt>.SO</tt> comme étant relatifs à cet
        emplacement.
      </p>
    </sect>

    <sect>Quel ensemble de macros utiliser&nbsp;?
      <p>
        Il y a de nombreux ensembles de macros étudiés spécialement pour écrire
        des pages de manuel. Ils sont habituellement dans le répertoire de
        macro de <tt>groff</tt> <it>/usr/lib/groff/tmac</it>. Les noms de
        fichiers sont du genre <it>tmac.&lt;quelque chose&gt;</it>, où
        <it>&lt;quelque-chose&gt;</it> est l'argument de l'option -m
        de <tt>groff</tt>. <tt>groff</tt> utilisera
        <it>tmac.&lt;quelque-chose&gt;</it> quand l'option <tt>-m
        &lt;quelque-chose&gt;</tt> sera donnée. Souvent, l'espace
        entre "-m" et  &lt;quelque-chose&gt; est oublié, on écrira
        donc <tt>groff -man</tt> pour formater des pages de manuel en
        utilisant l'ensemble de macro tman.an. Voilà la raison de ce
        nom bizarre "<it>tman.an</it>".
      </p>
      <p>
        En plus de <it>tman.an</it>, il existe un autre ensemble de macro
        populaire, <it>tman.doc</it>, originaire de l'université de
        Californie à Berkeley (UCB). De nombreuses pages de manuels de BSD
        l'utilisent et il semble que UCB en a fait son standard pour la
        documentation. Les macros de <it>tman.doc</it> sont plus souples
        mais, hélas, il y a des lecteurs de pages de manuels qui ne
        les utilisent pas mais qui appellent toujours <tt>groff -man</tt>. Par
        exemple, toutes les versions du programme <tt>xman</tt> que j'ai rencontrées
        faisaient la tête devant
        les pages de manuels requérant <it>tman.doc</it>. Donc faîtes-vous
        une faveur : utilisez <it>tmac.an</it>, utiliser un autre ensemble
        de macros est considéré comme hasardeux. <it>tmac.andoc</it> est
        un pseudo ensemble de macros qui regarde le source et charge soit
        <it>tmac.an</it> ou <it>tmac.doc</it>. En fait, tous les
        programmes de lecture du manuel devraient l'utiliser mais
        jusqu'à présent, peu le font, aussi il vaut mieux assurer le coup
        en se cantonnant au bon vieux <it>tmac.an</it>. Tout ce que je
        dirais à partir de maintenant concernant les macros est valable
        seulement pour <it>tmac.an</it>. Si vous voulez quand même utiliser
        les macros de <it>tmac.doc</it>, voici un pointeur vers leur
        documentation et un mode d'emploi très détaillé&nbsp;:
        <htmlurl url="http://www.bsdi.com/bsdi-man"
                 name="www.bsdi.com/bsdi-man">.
        Vous trouverez un formulaire de recherche sur cette page. Entrez
        <tt>mdoc</tt> et il vous trouvera <tt>mdoc(7)</tt> et
        <tt>mdoc.samples(7)</tt>, un didacticiel sur la réalisation des
        pages de manuel BSD.
        </p>
    </sect>

    <sect>Quels préprocesseurs puis-je utiliser&nbsp;?
      <p>
        <tt>groff</tt> est fourni avec au moins 3 préprocesseurs,
        <tt>tbl</tt>, <tt>eqn</tt> et <tt>pic</tt> (certains
        systèmes les nomment <tt>gtbl</tt>, <tt>geqn</tt> et
        <tt>gpic</tt>). Ils sont destinés à traduire leurs macros
        et leurs données en code source <tt>troff</tt> standard.
        <tt>tbl</tt> est un préprocesseur de tableaux,
        <tt>eqn</tt> en est un d'équation et de mathématiques et
        <tt>pic</tt> gère les images. Consultez leurs pages de
        manuel pour découvrir les fonctionalités qu'ils proposent.
      </p>
      <p>
        Mais autant être clair&nbsp;: n'écrivez pas de pages de manuel
        qui utilisent des préprocesseurs.
      </p>
      <p>
        <tt>eqn</tt> produira généralement un résultat catastrophique
        sur des périphériques du genre télétype, qui malheureusement
        représentent 99% des visualtions de pages de manuel. Par exemple
        <it>XAllocColor.3x</it> contient des formules avec des
        exposants. A cause de la nature de ces terminaux, l'exposant
        sera sur la même ligne que la base. &laquo;<it>N puissance
        deux</it>&raquo; s'affichera "N2".
      </p>
      <p>
        Il vaut mieux éviter <tt>tbl</tt> aussi, car je n'ai jamais vu aucun
        <tt>xman</tt> qui fonctionne avec lui.
        <tt>xman 3.1.6</tt> utilise la ligne de commande suivante pour
        formater les pages de manuel, par exemple <it>signal(7)</it>&nbsp;:
        <verb>
gtbl /usr/man/man7/signal.7 | geqn | gtbl | groff -Tascii -man \
/tmp/xmana01760 2> /dev/null
        </verb>
        qui coince sur toutes les sources utilisant <tt>gtbl</tt>, car
        sa sortie est redirigée encore une fois vers <tt>gtbl</tt>. Le
        résultat donne une page de manuel sans votre tableau. Je ne
        sais pas si c'est un bogue ou une particularité de
        <tt>gtbl</tt> qui s'étrangle sur sa propre sortie ou si
        <tt>xman</tt> devrait être un peu plus gentil et ne pas
        utiliser <tt>gtbl</tt> deux fois... De toute façon, si vous
        voulez un tableau, formatez-le vous-même et mettez-le entre
        les lignes <tt>.nf</tt> et <tt>.fi</tt> ce qui permettra de ne
        pas le formater. Vous ne pourrez pas avoir de gras ou
        d'italique par cette méthode mais elle permettra d'avoir votre
        tableau dans tous les cas.
      </p>
      <p>
        Je n'ai jamais vu une page de manuel nécessitant le
        préprocesseur <tt>pic</tt> mais je n'aimerais pas ça. Comme
        vous pouvez le voir plus haut, <tt>xman</tt> ne l'utilise pas
        et <tt>groff</tt> ferait sûrement la danse de Saint-Guy en
        voyant les données en entrée.
      </p>
    </sect>
    
    <sect>Dois-je distribuer les sources et/ou la documentation déjà formatée&nbsp;?
      <p>
        Voyons les avantages (+) et les inconvénients (-) de quelques
        possibilités choisies&nbsp;:
        <enum>
          <item>
            code source uniquement&nbsp;:
            <itemize>
              <item>
                (+) distribution plus petite&nbsp;;
              </item>
              <item>
                (-) inutilisable sur les systèmes ne disposant pas de
                <tt>groff</tt>.
              </item>
            </itemize>
          </item>
          <item>
            verison formatée non compactée uniquement&nbsp;:
            <itemize>
              <item>
                (+) utilisable même sur des systèmes dépourvus de
                <tt>groff</tt>&nbsp;;
              </item>
              <item>
                (-) l'utilisateur ne peut pas générer un fichier dvi
                ou PostScript&nbsp;;
              </item>
              <item>
                (-) gâchis de l'espace disque sur les systèmes sachant
                gérer aussi les pages compressées.
              </item>
            </itemize>
          </item>
          <item>
            version formatée et compactée seulement&nbsp;:
            <itemize>
              <item>
                (+) utilisables même sur des systèmes dépourvus de
                <tt>groff</tt>&nbsp;;
              </item
              <item>
                (-) l'utilisateur ne peut pas générer de fichier dvi
                ou PostScript&nbsp;;
              </item>
              <item>
                (-) quel format de compactage utiliser&nbsp;? .Z&nbsp;? .z ?
                .gz&nbsp;? Tous&nbsp;?.
              </item>
            </itemize>
          </item>
          <item>
            code source et la version formatée non compactée&nbsp;:
            <itemize>
              <item>
                (+) accessible même sur les systèmes ne disposant pas
                de <tt>groff</tt>&nbsp;;
              </item>
              <item>
                (-) taille de la distribution plus grande&nbsp;;
              </item>
              <item>
                (-) certains systèmes peuvent nécessiter des pages de
                manuels formattées et compactées&nbsp;;
              </item>
              <item>
                (-) informations redondantes sur les systèmes équipés
                de <tt>groff</tt>.
              </item>
            </itemize>
          </item>
        </enum>
      </p>
      <p>
        A mon avis, la meilleure solution est de distribuer uniquement
        le code source. L'argument selon lequel la documentation ne
        pourra pas être accessible sur les systèmes sans <tt>groff</tt>
        n'a aucune importance. Plus de 500 pages de manuel du Projet de
        Documentation de Linux ne sont que sous forme de code source.
        Les pages de manuel de XFree86 ne sont disponibles que sous
        forme de code source. Les pages de manuel de la FSF n'existent
        que sous forme de code source. En fait, j'ai rarement vu des
        logiciels distribués avec les pages de manuels formatées. Si un
        administrateur a besoin que les pages de manuel soient
        accessibles, il aura forcément installé <tt>groff</tt>.
      </p>
    </sect>
    
    <sect>Quelles sont les conventions pour les fontes&nbsp;?
      <p>
        Avant tout, n'utilisez pas les opérateurs directs de fonte comme
        <tt>\fB \fP</tt>, etc. Employez des macros avec des arguments.
        Cette méthode vous évitera une erreur classique&nbsp;: oublier un
        changement de fonte à la fin d'un mot ce qui provoque la
        continuation du gras ou de l'italique jusqu'au prochain
        changement de fonte. Croyez-moi, ça arrive plus souvent qu'on
        ne le pense&nbsp;!
      </p>
      <p>
        Les macros <it>tmac.an</it> offrent les possibilités
        suivantes&nbsp;:
        <itemize>
          <item>
            <tt>.B</tt> caractères gras
          </item>
          <item>
            <tt>.BI</tt> gras et italiques en alternance
          </item>
          <item>
            <tt>.BR</tt> gras et romain en alternance
          </item>
          <item>
            <tt>.I</tt> italiques
          </item>
          <item>
            <tt>.IB</tt> italiques et gras en alternance
          </item>
          <item>
            <tt>.IR</tt> italiques et romain en alternance
          </item>
          <item>
            <tt>.RB</tt> romain et gras en alternance
          </item>
          <item>
            <tt>.RI</tt> romain et italiques en alternance
          </item>
          <item>
            <tt>.SM</tt> taille réduite (9/10 du corps normal)
          </item>
          <item>
            <tt>.SB</tt> gras, taille réduite (NON petit et gras en
            alternance)
          </item>
        </itemize>
      </p>
      <p>
        X et Y en alternance signifie que les arguments impairs
        seront imprimés en X et les pairs en Y. Par exemple&nbsp;:
        <tscreen>
          <verb>
.BI "Arg 1 est gras, " "arg2 est en italiques, " "arg3 en gras"
          </verb
        </tscreen>
      </p>
      <p>
        Les guillemets sont nécessaires pour placer des espaces dans
        un argument.
      </p>
      <p>
        Voilà donc pour ce qui est possible. Voyons maintenant comment
        il faut utiliser ces possibilités (des parties ont été
        honteusement copiées de <tt>man(7)</tt>)&nbsp;:
      </p>
      <p>
        Bien qu'il existe de nombreuses conventions typographiques
        pour les pages de manuel dans le monde UNIX, l'existence de
        plusieurs centaines de pages de manuel spécifiques à Linux
        définit nos standards&nbsp;:
      </p>
      <p>
        Pour les fonctions, les arguments sont toujours en italiques,
        même dans la section SYNOPSYS, alors que le reste est en gras.
        Vous écrirez donc&nbsp;:
        <tscreen>
          <verb>
.BI "mafonction(int " argc ", char **" argv );
          </verb>
        </tscreen>
      </p>
      <p>
        Les noms de fichiers sont toujours en italiques, hormis dans
        la section SYNOPSYS où les fichiers à inclure sont en gras.
        Vous écrirez alors&nbsp;:
        <tscreen>
          <verb>
.I /usr/include/stdio.h
          </verb>
        </tscreen>
        et
        <tscreen>
          <verb>
.B #include <stdio.h>
          </verb>
        </tscreen>
      </p>
      <p>
        Les noms des macros, qui sont habituellement en majuscules,
        sont en gras&nbsp;:
        <tscreen>
          <verb>
.B MAXINT
          </verb>
        </tscreen>
      </p>
      <p>
        Lors de l'énumération d'une liste de codes d'erreurs, ces
        codes sont en gras. Cette liste fait généralement appel à la
        macro <tt>.TP</tt> (paragraphe avec titre) comme ci-dessous&nbsp;:
        <tscreen>
          <verb>
.TP
.B EBADF
.I fd n'est pas un descripteur de fichier valide
.TP
.B EINVAL
.I fd ne convient pas pour être lu
          </verb>
        </tscreen>
      </p>
      <p>
        Toute référence à une autre page de manuel (ou à la
        page courante) est en gras. Si le numéro de la section du
        manuel est indiqué, il s'écrit en roman, sans espace&nbsp;:
        <tscreen>
          <verb>
.BR man (7)
          </verb>
        </tscreen>
      </p>
      <p>
        Les acronymes sont plus élégants lorsqu'ils apparaissent dans
        un corps plus petit. Je recommande donc&nbsp;:
        <tscreen>
          <verb>
.SM UNIX
.SM ASCII
.SM TAB
.SM NFS
.SM LALR(1)
          </verb>
        </tscreen>
    </sect>
    
    <sect>Comment dois-je présenter ma page de manuel&nbsp;?
      <p>
        Voilà quelques conseils pour rendre votre documentation plus
        sûre, plus lisible et plus &laquo;formatable&raquo;&nbsp;:
        <itemize>
          <item>Les exemples doivent fonctionner&nbsp;: testez-les
            (utilisez le copier-coller pour passer à votre shell ce que
            contient votre page de manuel) et redirigez la sortie de
            votre commande dans votre page, ne tapez pas ce que vous
            PENSEZ que votre programme affichera.
          </item>
          <item>
            relisez-vous, corrigez toutes les éventuelles fautes de
            frappe ou d'orthographe, faîtes-vous relire par un tiers
            (surtout si vous ne rédigez pas le texte dans votre langue
            natale)&nbsp;. (d'ailleurs ce HOWTO n'a pas été relu...
            Y a-t-il un volontaire&nbsp;?)
          </item>
          <item>
            testez votre page de manuel&nbsp;: est-ce que
            <tt>groff</tt> trouve des erreurs lors du formatage&nbsp;?
            C'est agréable de trouver dans un commentaire la ligne de
            commande qu'il faut taper pour le formatage. Est-ce que la
            commande <tt>man(1)</tt> affiche des erreurs ou des
            avertissements lorsqu'on appelle "<tt>man
            votre_programme</tt>"&nbsp;? Est-ce que la façon dont
            <tt>man(1)</tt> utilise le système de formatage produit le
            résultat escompté&nbsp;? Est-ce que cela fonctionne aussi
            bien avec <tt>xman(1x)</tt> et <tt>tkman(1tk)</tt>&nbsp;?
            <tt>XFree86 3.1</tt> contient la version 3.1.6 de
            <tt>xman</tt> qui décompacte les pages avec&nbsp;:
            <tscreen>
              <verb>
gzip -c -d &lt; %s &gt; %s
zcat &lt; %s &gt; %s
              </verb>
            </tscreen>
          </item>
          <item>
            Est-ce que <tt>makewhatis(8)</tt> pourra extraire la ligne
            de description de la section NAME&nbsp;?
          </item>
        </itemize>
      </p>
    </sect>
    
    <sect>Comment puis-je avoir un texte en pur ASCII sans tous ces fichus ^H^ de contrôle&nbsp;?
      <p>
        Jetez un oeuil à la commande <tt>col(1)</tt>, <tt>col</tt>
        peut enlever ces caractères d'effacement. Pour les impatients,
        voici la commande&nbsp;:
        <tscreen>
          <verb>
$ groff -t -e -mandoc -Tascii manpage.1 | col -bx > manpage.txt
          </verb>
        </tscreen>
        Les options <tt>-t</tt> et <tt>-e</tt> disent à <tt>groff</tt>
        d'utiliser les préprocesseurs <tt>tbl</tt> et <tt>eqn</tt>.
        C'est inutile pour les pages de manuel ne nécessitant pas de
        préprocesseur mais cela ne gêne pas, si ce n'est une surcharge
        du processeur. D'un autre côté, ne pas utiliser <tt>-t</tt>
        alors qu'il est nécessaire fera que les tableaux seront très
        mal formatés. Vous pourrez même trouver ("deviner" serait un
        terme plus exact) la commande nécessaire pour traiter tel ou
        tel document groff (pas uniquement des pages de manuel) par le
        biais de <tt>grog</tt>&nbsp;: 
        <tscreen>
          <verb>
$ grog /usr/man/man7/signal.7 
groff -t -man /usr/man/man7/signal.7 
          </verb>
        </tscreen>
      </p>
      <p>
        En fait, <tt>grog</tt> signifie "<it>GROff Guess</it>", et cet outil
        fait bien ce qu'il dit (en anglais, guess = deviner...)&nbsp;: il tente de
        deviner la commande nécessaire pour formater un document groff
        en fonction de son contenu. S'il était parfait, nous n'aurions
        jamais plus besoin d'options. Mais s'il arrive qu'il détermine
        un mauvais jeu de macros, je ne l'ai par contre jamais
        vu se tromper sur les préprocesseurs à employer.
      </p>
      <p>
        Voici un petit script Perl réalisé par l'auteur de ce
        document, qui peut supprimer les en-têtes et les pieds de
        page, ce qui permet de gagner quelques longueurs de papier
        lorsque l'on imprime de longues et complexes pages de manuel.
        Sauvez-le dans un fichier nommé <it>strip-header</it> et
        mettez-le en mode 755.
        <tscreen>
          <verb>
#!/usr/bin/perl -n
#  pour qu'il avale tout le fichier en une seule fois:
undef $/;
#  on enleve les sauts de page:
s/\n{4}\S.{50,}\n{6}\S.{50,}\n{3}/\n/g;
#  le premier en-tete et le dernier pied de page:
s/\n\S.{50,}\n//g;
#  transorme deux ou plus lignes vides consecutives en une seule:
s/\n{3,}/\n\n/g;
#  et voila ce qui reste...
print; 
            </verb>
        </tscreen>
      </p>
      <p>
        Il faut appeler ce programme en tant que premier filtre après la
        comande man, car il se base sur le nombre de sauts de ligne
        issus de groff. Par exemple&nbsp;: 
        <tscreen>
          <verb>
$ man bash | strip-headers | col -bx > bash.txt
          </verb>
        </tscreen>
      </p>
    </sect>
    
    <sect>Comment avoir une belle page de manuel en PostScript &nbsp;?
      <p>
        <tscreen>
          <verb>
$ groff -t -e -mandoc -Tps manpage.1 > manpage.ps
          </verb>
        </tscreen>
        Imprimez-la à l'aide de votre imprimante PostScript préférée
        ou d'un interpréteur. Voir la section précédente pour les options.
      </p>
    <sect>Comment faire fonctionner les programmes <tt>apropos</tt> et <tt>whatis</tt>&nbsp;?
      <p>
        Supposons que vous recherchiez les compilateurs installés sur
        votre système et comment les invoquer (nous considérons le cas
        courant, où tout le manuel est en langue anglaise). Pour
        répondre à cette question (fréquemment posée), il faut
        faire&nbsp;:
        <tscreen>
          <verb>
$ apropos compiler
f77 (1) - Fortran 77 compiler
gcc (1) - GNU C and C++ compiler
pc (1) - Pascal compiler
          </verb
        </tscreen>
      </p>
      <p>
        <tt>apropos</tt> et <tt>whatis</tt> sont utilisées pour
        obtenir une réponse rapide sur les pages de manuels qui
        contiennent des informations sur un certain sujet. Les deux
        programmes cherchent dans des fichiers nommés
        <it>whatis</it> qui sont dans chaque
        répertoire de base du manuel. Comme je l'ai déjà dit, les
        fichiers de la base de données <it>whatis</it> contiennent une
        entrée d'une ligne pour chaque page de manuel dans
        l'arborescence des répertoires successifs. En fait, cette
        ligne est exactement celle de la section NAME (pour être
        précis&nbsp;: tout est réduit à une seule ligne et le tiret
        est supprimé, la section étant placée entre parenthèses). Ces
        fichiers sont créés à l'aide du programme
        <tt>makewhatis(8)</tt>. Il en existe plusieurs versions, donc
        référez-vous à la page de manuel du programme pour connaître
        les options possibles. Afin que <tt>makefile</tt> puisse
        extraire les sections NAME correctement, il est important que
        vous, le rédacteur du manuel, respectiez le format de cette
        section décrit dans la partie 2. La différence entre
        <tt>apropos</tt> et <tt>whatis</tt> est ce qu'ils recherchent et où.
        <tt>apropos</tt> (qui est l'équivalent de <tt>man -k</tt>)
        cherche la chaîne de caractères qui lui est passée en argument
        n'importe où dans la ligne alors que <tt>whatis</tt>
        (équivalent de <tt>man -f</tt>) recherche dans la
        partie avant le tiret un nom de commande complet. Par
        conséquence, <tt>whatis</tt> dira s'il y a un manuel de
        <tt>cc</tt> mais restera muet pour <tt>gcc</tt>.
        </p>
    </sect>
    <!-- section ajoutee dans la version francaise precedente -->
    <sect>La langue française
      <p>
        C'est bien sûr à vous de décider si vous allez rédiger votre
        manuel en français, en anglais ou dans ces deux langues. Le
        français possède des règles typographiques très différentes de
        l'anglais&nbsp;: n'espérez pas pouvoir les respecter avec les
        outils de formatage du manuel. Consultez la documentation de
        <tt>groff</tt> si vous désirez lui faire prendre en compte les motifs
        de césure de la langue de Molière, mais en ayant conscience
        que ce ne sera sans doute pas possible sur tous les systèmes
        sur lesquels votre documentation est susceptible d'être exploitée.
      </p>
      <p>
        Vous pouvez utiliser les caractères accentués, pourvu qu'ils soient
        saisis selon la norme ISO-8859-1 (standard sous Linux). Les
        pages devront alors être formatées avec l'option -Tlatin1 .
        Mais il faudra que toute la chaîne de visualisation soit
        capable de gérer les caractères ISO sur 8 bits, ce qui est
        rarement le cas sans une configuration particulière des
        utilitaires <tt>more</tt> ou <tt>less</tt> généralement
        employés.
      </p>
      <p>
        Vous voilà prévenu&nbsp;!
      </p>
    </sect>
    <sect>Les conditions de copie
      <p>
        Copyright 1995, 96, 97 Jens Schweikardt
        <htmlurl url="mailto:schweikh@noc.dfn.de"
        name="schweikh@noc.dfn.de">
      </p>
      <p>
        Téléphone&nbsp;: ++49 7151 909516
      </p>
      <p>
        Sauf mention contraire, les documents Linux <it>HOWTO</it>
        portent le copyright de leurs auteurs respectifs. Ils peuvent
        être reproduits et distribués en tout ou  partie, sur
        n'importe quel support physique ou électronique, à condition
        que cette notice soit incluse dans chaque copie. La
        redistribution est autorisée et encouragée&nbsp;; toutefois,
        l'auteur voudrait en être prévenu.
      </p>
      <p>
        Toutes les traductions, travaux dérivés ou compilation de
        travaux incluant des documents Linux <it>HOWTO</it> doivent
        être couverts par ce copyright. C'est-à-dire que vous ne
        pouvez pas produire un travail dérivé d'un HOWTO et imposer
        des restrictions supplémentaires sur sa distribution. Des
        dérogations à ces règles peuvent être accordées sous certaines
        conditions&nbsp;: contactez le coordinateur des Linux
        <it>HOWTO</it> dont l'adresse est donnée plus loin.
      </p>
      <p>
        En résumé, nous désirons promouvoir la diffusion de ces
        informations à travers tous les canaux de communication
        possibles. Cependant, nous voulons conserver la propriété des
        <it>HOWTO</it> et aimerions être tenu au courant de tout
        projet de redistribution.
      </p>
      <p>
        Si vous avez des questions, contactez Greg Hankins, le
        coordinateur, par courrier électronique à l'adresse <htmlurl
        url="mailto:gregh@sunsite.unc.edu"
        name="gregh@sunsite.unc.edu">.
      </p>
    </sect>
  </article>

Site hébergé sur un Cloud Public IKOULA Ikoula