man-pages

NOM

SYNOPSIS

DESCRIPTION

Sections des pages de manuel

1 Commandes de l’utilisateur (programmes)

Commandes pouvant être invoquées par l'utilisateur depuis un interpréteur de commandes.

2 Appels système

Fonctions enveloppant les opérations réalisées par le noyau.

3 Fonctions des bibliothèques

Toutes les fonctions des bibliothèques en excluant les enveloppes d’appel système (la plupart des fonctions de la libc).

4 Fichiers spéciaux (périphériques)

Fichiers présents dans /dev permettant l’accès aux périphériques par l’intermédiaire du noyau.

5 Formats de fichier et fichiers de configuration

Descriptions des formats de fichier lisibles par un humain et des fichiers de configuration.

6 Jeux

Jeux et petits programmes amusants disponibles sur le système.

7 Vue d’ensemble, conventions et éléments divers

Vues d’ensemble ou descriptions de divers sujets, des protocoles et conventions, des jeux de caractères normalisés, de la structure du système de fichiers et d'autres choses diverses.

8 Commandes d'administration du système

Commandes comme mount(8), la plupart exécutables uniquement par le superutilisateur.

Paquet de macros

Conventions pour la présentation des fichiers sources

Ligne de titre

.TH titre section date source section_manuel

Les arguments de cette commande sont les suivants :

titre

Le titre de la page de manuel, en majuscules (par exemple MAN-PAGES).

section

Le numéro de section dans laquelle la page devrait être placée (par exemple, 7).

date

La date du dernier changement non trivial effectué sur cette page de manuel. Au sein du projet man-pages, les mises à jour des étiquettes temporelles sont automatiquement effectuées par des scripts, de sorte qu'il n'est pas nécessaire de les mettre à jour lors la fourniture d'un correctif. Les dates devraient être écrites sous la forme AAAA-MM-JJ.

source

Le nom et la version du projet fournissant la page de manuel (pas nécessairement le paquet fournissant la fonctionnalité).

section_manuel

Normalement cela devrait être vide puisque la valeur par défaut devrait être la bonne.

Sections dans une page de manuel

NAME (NOM)
BIBLIOTHÈQUE	[Normalement seulement dans les Sections 2 et 3]
SYNOPSIS
CONFIGURATION	[Normalement seulement dans la Section 4]
DESCRIPTION
OPTIONS	[Normalement seulement dans les Sections 1 et 8]
CODE DE RETOUR	[Normalement seulement dans les Sections 1 et 8]
VALEUR RENVOYÉE	[Normalement seulement dans les Sections 2 et 3]
ERREURS	[Typiquement seulement dans les Sections 2 et 3]
ENVIRONNEMENT
FICHIERS
ATTRIBUTS	[Normalement seulement dans les Sections 2 et 3]
VERSIONS	[Normalement seulement dans les Sections 2 et 3]
STANDARDS
HISTORIQUE
NOTES
AVERTISSEMENTS
BOGUES
EXEMPLES
AUTEURS	[Déconseillé]
SIGNALER DES BOGUES	[Non utilisé dans man-pages]
COPYRIGHT	[Non utilisé dans man-pages]
SEE ALSO (VOIR AUSSI)

Lorsque l'une des sections traditionnelles s'applique, utilisez-la ; cette cohérence rend l'information plus facile à comprendre. Si cela est nécessaire, vous pouvez créer vos propres titres de section si cela rend les choses plus compréhensibles (particulièrement pour les pages des sections 4 et 5). Cependant, avant de faire cela, vérifiez qu'aucun titre de section traditionnel ne peut être utilisé avec des sous-sections (.SS) dans celle-ci.

La liste suivante décrit le contenu de chacune des sections ci-dessus.

NAME (NOM)

Nom de cette page de manuel

See man(7) for important details of the line(s) that should follow the .SH NAME command. All words in this line (including the word immediately following the "\-") should be in lowercase, except where English or technical terminological convention dictates otherwise.

BIBLIOTHÈQUE

Bibliothèque fournissant un symbole.

Cela montre le nom courant de la bibliothèque et, entre parenthèses, le nom du fichier de la bibliothèque et, si nécessaire, l'indicateur nécessaire à l’éditeur de liens pour lier un programme avec elle : (libfoo[, -lfoo]).

SYNOPSIS

Bref résumé de l’interface de la commande ou de la fonction.

Pour les commandes, ce paragraphe montre la syntaxe et les arguments de la commande (y compris les options). Les caractères en gras marquent le texte invariable et ceux en italique indiquent les arguments remplaçables. Les crochets « [] » encadrent les arguments facultatifs, les barres verticales « | » séparent les alternatives et les points de suspension « ... » peuvent être des arguments répétés. Pour les fonctions, cela contient toutes les déclarations de données ou les directives #include, suivies de la déclaration de fonction.

Si une macro de test de fonctionnalité doit être définie pour obtenir la déclaration d'une fonction (ou d'une variable) dans un fichier d'en-tête, alors la section SYNOPSIS devrait l'indiquer, comme décrit dans feature_test_macros(7).

CONFIGURATION

Détails de configuration pour un périphérique.

Cette section est présente normalement que dans les pages de la section 4.

DESCRIPTION

Explication sur ce que le programme, la fonction ou le format réalise.

Cette section décrit les interactions avec les fichiers et l'entrée standard, et ce qui est produit sur la sortie standard ou d'erreur. Les détails d'implémentation internes sont omis sauf s'ils sont critiques pour comprendre l'interface. L’utilisation habituelle est décrite et la section OPTIONS est utilisée pour les détails.

La description d'un nouveau comportement ou de nouveaux drapeaux d'un appel système ou d'une fonction d'une bibliothèque doit préciser la version du noyau ou de la bibliothèque C qui a introduit ce changement. Il est recommandé de noter cette information à propos des drapeaux sous la forme d'une liste .TP, comme ci-dessous dans le cas d'un drapeau d'appel système :

XYZ_FLAG (depuis Linux 3.7)

Description du drapeau...

Préciser la version est particulièrement utile aux utilisateurs qui sont contraints d’utiliser d'anciennes versions du noyau ou de la bibliothèque C, ce qui est par exemple courant dans le cas des systèmes embarqués.

OPTIONS

Descriptions des options de ligne de commande acceptées par un programme et leur influence sur son comportement.

Cette section ne devrait être utilisée que pour les pages de manuel des sections 1 et 8.

EXIT STATUS (CODE DE RETOUR)

Liste des codes de retour d'un programme et des conditions de renvoi de ces valeurs.

Cette section ne devrait être utilisée que pour les pages de manuel des sections 1 et 8.

RETURN VALUE (VALEUR RENVOYÉE)

Pour les pages des sections 2 et 3, cette section donne une liste des valeurs qu'une routine de bibliothèque renverra à l'appelant et les conditions qui provoquent ces retours.

ERRORS (ERREURS)

Pour les pages des sections 2 et 3, cette section contient une liste des valeurs possibles de errno en cas d'erreur, avec la description des causes de ces erreurs.

Quand des conditions différentes produisent la même erreur, l’approche à préférer est de créer plusieurs entrées de liste séparées (avec des noms d’erreur dupliqués) pour chacune des conditions. Cela clarifie les différences de conditions, rend la liste plus facile à lire et permet aux méta-informations (par exemple, le numéro de version du noyau dans laquelle la condition est devenu applicable) d’être plus facilement caractérisées pour chaque condition.

La liste d’erreurs devrait être triée par ordre alphabétique.

ENVIRONMENT (ENVIRONNEMENT)

Liste de toutes les variables d'environnement affectant le programme ou la fonction, ainsi que de leurs effets.

FILES (FICHIERS)

Liste de tous les fichiers utilisés par le programme ou la fonction, tels les fichiers de configuration, les fichiers de démarrage et les fichiers manipulés directement par le programme.

Le chemin d'accès complet de ces fichiers doit être donné ainsi que le mécanisme d'installation utilisé pour modifier la partie répertoire afin de satisfaire aux préférences de l’utilisateur. Pour la plupart des programmes, l'installation par défaut se fait dans /usr/local, aussi, votre page de manuel de base devrait utiliser /usr/local comme base.

ATTRIBUTES (ATTRIBUTS)

Résumé des divers attributs de la ou des fonctions documentées sur cette page. Consulter attributes(7) pour de plus amples détails.

VERSIONS

A summary of systems where the API performs differently, or where there's a similar API.

STANDARDS

Descriptions des normes ou conventions liées à la fonction ou à la commande décrite par la page de manuel.

Les termes privilégiés à utiliser pour les différentes normes sont listés dans les rubriques de standards(7)

This section should note the current standards to which the API conforms to.

If the API is not governed by any standards but commonly exists on other systems, note them. If the call is Linux-specific or GNU-specific, note this. If it's available in the BSDs, note that.

Si cette section ne consiste qu'en une liste de normes (ce qui est d'habitude le cas), terminez la liste par un point (« . »).

HISTORY

Court résumé de la version du noyau Linux ou de la glibc où l'appel système ou la fonction de bibliothèque est apparue ou dont le fonctionnement est modifié de manière significative.

As a general rule, every new interface should include a HISTORY section in its manual page. Unfortunately, many existing manual pages don't include this information (since there was no policy to do so when they were written). Patches to remedy this are welcome, but, from the perspective of programmers writing new code, this information probably matters only in the case of kernel interfaces that have been added in Linux 2.4 or later (i.e., changes since Linux 2.2), and library functions that have been added to glibc since glibc 2.1 (i.e., changes since glibc 2.0).

La page de manuel syscalls(2) fournit également des informations de versions de noyau dans lesquelles sont apparus les appels système.

Old versions of standards should be mentioned here, rather than in STANDARDS, for example, SUS, SUSv2, and XPG, or the SVr4 and 4.xBSD implementation standards.

NOTES

Notes diverses

Pour les pages des sections 2 et 3, il peut être utile d'utiliser des sous-sections (SS) appelées Linux Notes (Notes sur Linux) ou glibc Notes (Notes sur la glibc).

Dans la section 2, le titre C library/kernel differences est à utiliser pour délimiter les notes décrivant les différences (s’il en existe) entre la fonction C d’enveloppe de bibliothèque pour un appel système et l’interface brute d’appel système fournie par le noyau.

AVERTISSEMENTS

Avertissements sur une mauvaise utilisation courante d’une API, qui ne constitue pas un bogue de celle-ci, ni un défaut de conception.

BUGS (BOGUES)

Liste des limitations, des défauts ou des inconvénients recensés, ainsi que des sujets à débat.

EXAMPLES (EXEMPLES)

Un ou plusieurs exemples d'utilisation de la fonction, du fichier ou de la commande.

Pour plus de détails sur l'écriture d'exemples de programme, consultez Exemples de programme ci-dessous.

AUTHORS (AUTEURS)

Liste des auteurs de la documentation ou du programme.

L'utilisation d'une section AUTHORS est fortement déconseillée. En général, il vaut mieux ne pas encombrer chaque page de manuel avec une liste (potentiellement longue) d'auteurs. Si vous écrivez ou modifiez de façon importante une page, ajoutez une notice de copyright en commentaire dans le fichier source. Si vous êtes l'auteur d'un pilote de périphérique et voulez inclure une adresse pour signaler les bogues, placez-la dans la section BUGS.

SIGNALER DES BOGUES

Le projet man-pages n’utilise pas de section REPORTING BUGS dans les pages de manuel. La manière de signaler des bogues est à la place indiquée dans la section COLOPHON générée par un script. Cependant, divers projets utilisent une section REPORTING BUGS. Il est recommandé de la placer près de la fin de page.

COPYRIGHT

Le projet man-pages n’utilise pas de section COPYRIGHT dans les pages de manuel. Les informations de droits d’auteur sont à la place entretenues dans le source de la page. Dans les pages incluant cette section, il est recommandée de la placer en bas de page, juste au-dessus de la section SEE ALSO.

SEE ALSO (VOIR AUSSI)

Liste des pages de manuel (séparées par des virgules) ayant un rapport, éventuellement suivie par d’autres pages ou documents ayant un rapport.

La liste devrait être classée selon l'ordre des sections puis de façon alphabétique. Ne terminez pas la liste par un point.

Where the SEE ALSO list contains many long manual page names, to improve the visual result of the output, it may be useful to employ the .ad l (don't right justify) and .nh (don't hyphenate) directives. Hyphenation of individual page names can be prevented by preceding words with the string "\%".

Étant donné la nature indépendante et distribuée des projets logiciels au code source ouvert (FOSS) et de leur documentation, il est parfois nécessaire (et dans de nombreux cas souhaitable) que la section SEE ALSO inclut des références vers des pages de manuel fournies par d’autres projets.

CONVENTIONS DE FORMATAGE ET DE FORMULATION

SYNOPSIS

In general, where more than one function prototype is shown in the SYNOPSIS, the prototypes should not be separated by blank lines. However, blank lines (achieved using .P) may be added in the following cases:

-

pour la séparation de longues listes de prototypes de fonctions en groupes de même sujet (consulter par exemple list(3));

-

dans d’autres cas pouvant améliorer la lisibilité.

Dans le SYNOPSIS, un prototype de fonction long peut nécessiter d’être continué dans une nouvelle ligne. Celle-ci sera indentée selon les règles suivantes :

(1)

S’il existe un seul prototype devant être continué, alors la ligne de continuation doit être alignée de façon à ce que lorsque la page est rendue dans un périphérique dont la fonte est de largeur fixe (par exemple, xterm), la ligne de continuation débute juste en dessous du début de la liste d’arguments de la ligne au-dessus (exception : l’indentation peut être ajustée si nécessaire pour empêcher une très longue ligne de continuation ou une autre ligne de continuation si le prototype est très long). Un exemple :

int tcsetattr(int fd, int optional_actions,
              const struct termios *termios_p);

(2)

Mais, quand plusieurs fonctions dans le SYNOPSIS nécessitent des lignes de continuation alors que les noms de fonction sont de différentes longueurs, alors l’alignement des lignes de continuation doit débuter dans la même colonne. Cela fournit un rendu plus agréable dans une sortie PDF (parce que le SYNOPSIS utilise une fonte de taille variable où le rendu des espaces est plus étroit que celui de la plupart des caractères). Un exemple :

int getopt(int argc, char * const argv[],
           const char *optstring);
int getopt_long(int argc, char * const argv[],
           const char *optstring,
           const struct option *longopts, int *longindex);

VALEUR RENVOYÉE

ATTRIBUTS

-

entourer la table dans cette section d'une paire .ad l/.ad pour désactiver le remplissage de texte et d'une paire .nh/.hy pour désactiver la coupure des mots en fin de ligne ;

-

s'assurer que la table occupe toute la largeur de la page à l’aide de la description lbx pour une des colonnes (habituellement la première colonne, bien que dans certains cas ce soit la dernière colonne si elle contient beaucoup de texte) ;

-

ne pas hésiter à utiliser la paire de macros T{/T} pour permettre aux cellules de la table d’être découpées en plusieurs lignes (en gardant en tête que les pages peuvent quelquefois être rendues en moins de 80 colonnes.

Pour des exemples de tout cela, consultez le code source de diverses pages.  

GUIDE DE STYLE

Utilisation de formulation neutre

Conventions typographiques pour les pages de manuel décrivant des commandes

Le nom de la commande et de ses options devraient toujours être en caractères gras.  

Conventions typographiques pour les pages de manuel décrivant des fonctions

int mafonction(int argc, char **argv);

Les noms de variables devraient, tout comme les noms de paramètres, être indiqués en italique.

Toute référence au sujet de la page de manuel courante devrait être écrite avec le nom en caractères gras suivi par une paire de parenthèses en caractères romains (normaux). Par exemple, dans la page fcntl(2), les références au sujet de la page devrait être écrites fcntl(). La façon privilégiée d'écrire cela dans le fichier source est :

    .BR fcntl ()

(Using this format, rather than the use of "\fB...\fP()" makes it easier to write tools that parse man page source files.)  

Utilisation de nouvelles lignes sémantiques

Listes

Paragraphes avec étiquettes

Ils sont utilisés pour une liste d’étiquettes et leurs descriptions. Quand les étiquettes sont des constantes (soit des macros ou des nombres), elles sont en gras. Utilisez la macro .TP.

Cette sous-section « Paragraphes avec étiquettes » constitue elle-même un exemple.

Listes ordonnées

Les éléments sont précédés par un nombre entre parenthèses (1), (2). Ces derniers représentent un succession d’étapes qui ont un ordre.

S’il existe des sous-étapes, elles seront numérotées comme (4.2).

Listes positionnelles

Les éléments sont précédés par un nombre (indice) entre crochets [4], [5]. Ces derniers représentent des champs dans un ensemble. Le premier indice sera :

0

quand il représente des champs dans une structure de données en C, pour être cohérent avec les tableaux ;

1

quand il représente des champs d’un fichier, pour être cohérent avec des outils comme cut(1).

Liste d’alternatives

Les éléments sont précédés par une lettre entre parenthèses (a), (b). Ces dernières représentent une liste d’alternatives exclusives (normalement).

Listes à puces

Elements are preceded by bullet symbols (\[bu]). Anything that doesn't fit elsewhere is usually covered by this type of list.

Notes numérotées

Ce ne sont pas réellement des listes, mais leur syntaxe est identique à celle des « listes positionnelles ».

Il devrait toujours y avoir exactement deux espaces entre le symbole de la liste et les éléments. Cela ne s’applique pas aux « paragraphes avec étiquettes » qui utilisent les règles d’indentation par défaut.  

Conventions typographiques (générales)

Les noms de fichiers, que ce soit des chemins ou des références à des fichiers d’en-tête, sont toujours en italique (par exemple <stdio.h>), sauf dans la section SYNOPSIS où les fichiers inclus sont en caractères gras (par exemple #include <stdio.h>). Lorsque vous faites référence à un fichier d'en-tête standard, indiquez le fichier d'en-tête entouré de chevrons, de la même manière que dans un fichier source C (par exemple, <stdio.h>).

Les macros spéciales, généralement en majuscules, sont en caractères gras (par exemple MAXINT). Exception : NULL ne doit pas être en gras.

Dans l'énumération d'une liste de codes d'erreur, les codes sont en caractères gras, et la liste utilise normalement la macro .TP.

Les commandes complètes devraient, si elles sont longues, être écrites sous une forme indentée, précédées et suivies d’une ligne vide, par exemple :

man 7 man-pages

If the command is short, then it can be included inline in the text, in italic format, for example, man 7 man-pages. In this case, it may be worth using nonbreaking spaces (\~) at suitable places in the command. Command options should be written in italics (e.g., -l).

Les expressions, si elles ne sont pas écrites sur une ligne séparée indentée, devraient être mises en italique. Ici aussi, l'utilisation d'espaces insécables est appropriée si l'expression est mélangée à du texte normal.

Pour montrer des sessions d’interpréteur de commandes, les saisies de l’utilisateur devraient être écrites en caractères gras.

$ date Thu Jul 7 13:01:27 CEST 2016

Toute référence à une autre page de manuel devrait être écrite avec le nom en caractères gras toujours suivi du numéro de section en caractères romains (normaux), sans espace intermédiaire (par exemple intro(2)). Dans le source, la façon préconisée est :

    .BR intro (2)

(Inclure le numéro de section dans les références croisées permet à des outils comme man2html(1) de créer des liens hypertextes appropriés)

Les caractères de contrôle devraient être écrits en gras, sans guillemets. Par exemple : haX.  

Orthographe

En plus des différences d’orthographe bien connues, quelques autres subtilités sont à surveiller :

-

L’anglais américain a tendance à utiliser les formes « backward », « upward », « toward », etc., au lieu des formes britanniques « backwards », « upwards », « towards », etc.

-

Les avis divergent entre « acknowledgement » et « acknowledgment ». Ce dernier prédomine, mais n’est pas toujours utilisé en anglais-américain. POSIX et la licence BSD utilisent la première orthographe. Dans le projet man-pages de Linux, c'est « acknowledgement » qui est utilisé.

Numéros de version BSD

Capitalisation

.SS Unicode sous Linux  

Indentation des définitions de structure, des journaux d’interpréteur, etc.

.P .in +4n .EX int main(int argc, char *argv[]) {
    return 0; } .EE .in .P  

Termes privilégiés

Consultez la section Écriture des mots composés épithètes ci-dessous.  

Termes à éviter

Marques déposées

DG/UX

HP-UX

UNIX

UnixWare

NULL, NUL, pointeur NULL et octet NULL

Le terme à préférer pour le pointeur est « null pointer » (pointeur NULL) ou simplement « NULL ». Éviter d’écrire « NULL pointer ».

Le terme à préférer pour l’octet est « null byte » (octet NULL). Évitez d’écrire « NUL » car cela pourrait être facilement confondu avec « NULL ». Évitez aussi les termes « zero byte » (octet zéro) et « null character » (caractère NULL). L’octet qui termine une chaîne en C devrait être décrit comme « the terminating null byte » (l’octet NULL final). Les chaînes peuvent être décrites comme « null-terminated » (terminées par NULL), mais évitez « NUL-terminated » (terminées par NUL).  

Liens hypertextes

BROWSER=firefox man -H nom_de_page  

Utilisation de e.g., i.e., etc., a.k.a., et autres

Le seul endroit où ce genre d’abréviation pourrait être acceptable est dans les parenthèses courtes (e.g., like this one).

Toujours inclure les points dans ces abréviations comme ici. De plus en anglais, « e.g. » et « i.e. » devraient toujours êtres suivies d’une virgule.  

Tirets longs

Écriture des mot composés épithètes

32-bit value

command-line argument

floating-point number

run-time check

user-space function

wide-character string

Séparation des mots avec les préfixes multi, non, pre, re, sub, etc.

interprocess

multithreaded

multiprocess

nonblocking

nondefault

nonempty

noninteractive

nonnegative

nonportable

nonzero

preallocated

precreate

prerecorded

reestablished

reinitialize

rearm

reread

subcomponent

subdirectory

subsystem

Les tirets sont gardés en anglais lorsque les préfixes sont utilisés dans des mots anglais non standard, avec les marques déposées, les noms propres, les acronymes ou les mots composés. Quelques exemples :

non-ASCII

non-English

non-NULL

non-real-time

Enfin, remarquez qu’en anglais « re-create »(recréer) et « recreate » (s’amuser) sont deux mots différents et que c’est sans doute le premier qu’il faut utiliser.  

Génération des glyphes optimaux

\-

Ce guide s’applique aussi aux exemples de code.

L’utilisation d’un vrai signe moins a pour buts :

-

fourniture d’un meilleur rendu dans diverses cibles autres que les terminaux ASCII, particulièrement pour les PDF et les terminaux adaptés à l’Unicode/UTF-8 ;

-

pour créer des glyphes qui, s’ils sont copiés depuis des rendus de page, produiront un vrai signe moins s’ils sont collés dans un terminal.

To produce unslanted single quotes that render well in ASCII, UTF-8, and PDF, use "\[aq]" ("apostrophe quote"); for example

\[aq]C\[aq]

où C est le caractère protégé. Ce guide s’applique aussi aux constantes caractère utilisées dans les exemples de code. Dans la traduction en français, si possible, préférez la forme typographique en vigueur (par exemple : « C »).

Lorsque qu’un caret approprié (ha) dont un bon rendu dans un terminal et en PDF est nécessaire, utilisez « \[ha] ». Cela est particulièrement nécessaire dans les exemples de code, pour obtenir un rendu élégant du caret en PDF.

L’utilisation d’un caractère nu « ~ » aboutit à un mauvais rendu en PDF. Utilisez plutôt « \[ti] ». Cela est particulièrement nécessaire dans les exemples de code, pour obtenir un rendu élégant du tilde en PDF.  

Programmes d'exemples et sessions d’interpréteur.

-

Les programmes d'exemple devraient être écrits en C.

-

Un programme d'exemple n'est nécessaire et utile que s'il montre quelque chose qui ne peut pas être fourni facilement dans une description textuelle de l'interface. Un programme d'exemple qui ne fait qu'appeler une fonction ne sert en général à rien.

-

Les programmes d’exemple devraient idéalement être courts (par exemple, un bon programme peut être souvent fourni avec moins de 100 lignes de code), quoique dans certains cas un programme plus long soit nécessaire pour illustrer convenablement l’utilisation d’une API.

-

Du code expressif est apprécié.

-

Des commentaires devraient être inclus là où c’est utile. Les phrases complètes dans les commentaires autonomes devraient être terminées par un point. Les points devraient être généralement omis dans les commentaires « d’étiquettes » (c’est-à-dire des commentaires qui sont placés sur la même ligne de code) — dans tous les cas de tels commentaires sont typiquement de courtes phrases plutôt que des phrases complètes.

-

Les programmes d'exemple devraient faire une vérification d’erreurs après les appels système et les appels de fonction de bibliothèque.

-

Les programmes d'exemple devraient être complets et compiler sans avertissements avec cc -Wall.

-

Si possible et raisonnable, les programmes d'exemples doivent permettre d'expérimenter, en changeant de comportement en fonction des entrées (arguments de ligne de commande ou entrées lues par le programme).

-

Les programmes d'exemple doivent être mis en forme dans le style de Kernighan et Ritchie, avec des indentations de quatre espaces (évitez le caractère tabulation dans les fichiers source). La commande suivante peut être utilisée pour mettre en forme le code source vers quelque chose proche du style préféré :

indent -npro -kr -i4 -ts4 -sob -l72 -ss -nut -psl prog.c

-

Par cohérence, tous les programmes d’exemple devraient se terminer par une des deux formes suivantes :

exit(EXIT_SUCCESS); exit(EXIT_FAILURE);

Évitez d’utiliser les formes suivantes pour terminer un programme :

exit(0); exit(1); return n;

-

Si un texte d’explication complète précède le code source du programme, indiquez le code source à l’aide d’un titre de sous-section Source du programme, comme :

.SS Source du programme

Toujours faire comme cela si le texte d’explication contient un journal de session d’interpréteur.

Si vous incluez un journal de session d'interpréteur de commandes pour démontrer l'utilisation d'un programme ou d'autres fonctionnalités système :

-

placez le journal de session au dessus du code source ;

-

indentez le journal de session par quatre espaces ;

-

mettez le texte entré par l'utilisateur en gras pour le distinguer de la sortie produite par le système.

Pour voir à quoi les programmes d'exemples devraient ressembler, consultez wait(2) et pipe(2).  

EXEMPLES

VOIR AUSSI

TRADUCTION

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à

Index

NOM

SYNOPSIS

DESCRIPTION

Sections des pages de manuel

Paquet de macros

Conventions pour la présentation des fichiers sources

Ligne de titre

Sections dans une page de manuel

CONVENTIONS DE FORMATAGE ET DE FORMULATION

SYNOPSIS

VALEUR RENVOYÉE

ATTRIBUTS

GUIDE DE STYLE

Utilisation de formulation neutre

Conventions typographiques pour les pages de manuel décrivant des commandes

Conventions typographiques pour les pages de manuel décrivant des fonctions

Utilisation de nouvelles lignes sémantiques

Listes

Conventions typographiques (générales)

Orthographe

Numéros de version BSD

Capitalisation

Indentation des définitions de structure, des journaux d’interpréteur, etc.

Termes privilégiés

Termes à éviter

Marques déposées

NULL, NUL, pointeur NULL et octet NULL

Liens hypertextes

Utilisation de e.g., i.e., etc., a.k.a., et autres

Tirets longs

Écriture des mot composés épithètes

Séparation des mots avec les préfixes multi, non, pre, re, sub, etc.

Génération des glyphes optimaux

Programmes d'exemples et sessions d’interpréteur.

EXEMPLES

VOIR AUSSI

TRADUCTION