Template formats reference

Updated 5 Novembre 2026

Une page pour celui qui choisit la valeur format= de son fichier de configuration. Un format répond à trois questions de son fichier de configuration. Un format répond à trois questions

Une page pour celui qui choisit la valeur format= de son fichier de configuration. Un format répond à trois questions de son fichier de configuration. Un format répond à trois questions

de son fichier de configuration. Un format répond à trois questions de son fichier de configuration. Un format répond à trois questions

de son fichier de configuration. Un format répond à trois questions de son fichier de configuration. Un format répond à trois questions : à quoi ressemble un enregistrement dans le fichier, ce qui sépare un enregistrement d'un autre et comment modifier ou supprimer un enregistrement déjà existant. Chaque section ci-dessous porte sur un format : d'abord à quoi ressemble le fichier, puis comment s'écrit la ligne, puis comment modifier un enregistrement.

Ce référentiel est à jour pour cl-core 3.7.6.8. Il y a 29 noms opérationnels : 26 formats, un alias (proftpd) et deux types intégrés (raw, bin) ; un nom de plus issu de l'ancienne documentation, ldif, est analysé à la fin de la page.

Le nom du format décrit la syntaxe, et non le programme. Le nom format= est choisi d'après la façon dont le fichier est analysé, et non d'après le nom du service configuré. D'où des surprises comme /etc/pulse/daemon.conf avec format=postfix : le format convient à tout fichier de la forme "clé = valeur", à qui qu'il appartienne.

Fichiers ini avec sections

Ce que cette famille a en commun : le fichier est découpé en groupes entre crochets, et chaque ligne à l'intérieur d'un groupe définit un paramètre. La valeur est modifiée en répétant dans le modèle la même ligne avec le même nom de clé dans le même groupe ; un enregistrement peut être supprimé en plaçant un `!`` перед именем ключа.

samba

L'ini classique : des groupes de la forme [group name], et à l'intérieur d'eux des lignes key = value. Les espaces autour de = ne signifient rien. Les enregistrements sont séparés par un saut de ligne, et # et ;``, стоящие в начале строки. Un enregistrement peut être supprimé par un!key=;+key=ajoute une valeur à une liste délimitée. Le ++append++ par défaut estjoin`.

Il configure /etc/samba/smb.conf et les fichiers *.env de Calculate Utilities.

kde

Il se comporte comme samba, avec deux différencesils sont visibles comme faisant partie du nom et de la valeur. Le commentaire est uniquement #, et les enregistrements sont séparés par un saut de ligne. Le append par défaut est join.

Un piège au niveau de la clé : le format ne comprend pas les préfixes + et -. L'enregistrement +key=value n'additionnera pas les valeurs, il créera un nouveau paramètre nommé +key, qui ne correspondra jamais à un existant ; il en va de même pour -key. Supprimez par !ключ=.

compiz

Malgré sa place dans l'ancienne documentation, c'est un format ini, et non XML : le fichier ressemble à des groupes [name] avec des lignes key = value à l'intérieur. Les espaces autour de = ne signifient rien, le commentaire est #, et les enregistrements sont séparés par un saut de ligne. Le append par défaut est join.

ldap

Analyse des enregistrements d'annuaire

Analyse des enregistrements d'annuaire : la ligne ressemble à key value - le nom et la valeur sont séparés par des espaces, et ils peuvent être plusieurs. Le commentaire est #, les enregistrements sont séparés par un saut de ligne, et le append par défaut est join. Les valeurs qui se comportent comme des listes s'écrivent en seplist : l'attribut type="seplist" avec l'action avec l'action join..

Pour les enregistrements d'annuaire, utilisez précisément ce format : ldif n'est pas fourni (voir ci-dessous).

plasma

Il se comporte comme samba, mais l'en-tête de groupe peut être une chaîne : [AC][DPMSControl] décrit un groupe imbriqué, et non deux groupes voisins. La ligne est key=value, le commentaire est #, les enregistrements sont séparés par un saut de ligne, et le append par défaut est join.

Utilisé pour les fichiers .config/*rc ; l'exemple est powermanagementprofilesrc dans 6_ac_desktop_profile.

Fichiers clé = valeur sans sections

Ces formats se distinguent de la famille ini par l'absence de groupes : chaque ligne définit un paramètre à elle seule, et il n'est pas nécessaire de le chercher à l'intérieur d'une section. Ils se distinguent par ce qui se trouve entre le nom et la valeur (=, un espace ou plusieurs), par ce qui sépare un enregistrement d'un autre (un saut de ligne ou ;) и какой символ служит комментарием. La valeur est modifiée en répétant la ligne avec le même nom.

openrc

Les fichiers /etc/conf.d/* : sans groupes, une ligne par paramètre, la ligne ressemble à KEY="value". Le commentaire est #, les enregistrements sont séparés par un saut de ligne, et le append par défaut est join.

Il se comporte comme procmail (ci-dessous), à une différence près : les noms de paramètres ne sont pas sensibles à la casse, donc un même nom en majuscules et en minuscules est un seul et même enregistrement.

procmail

Un fichier sans groupeselle ne participe pas à la correspondance et tombe du résultat lors de la fusion du modèle. Si une telle ligne doit survivre, il faut l'affecter à un format qui la comprend, ou la protéger par le mode append de la cible.

De vrais exemples sont les fichiers de configuration du noyau dans 2_ac_install_merge/sys-apps/openrc/ (desktop_performance.conf, network_buffers.conf) avec path=/etc/sysctl.d :

# Calculate path=/etc/sysctl.d format=procmail os_subsystem!=lxc os_linux_system==desktop
vm.vfs_cache_pressure=50
net.ipv4.tcp_fin_timeout=15

postfix

Des paires key = value à plattout le fichier est lu comme une seule liste à plat de paramètres.

Un exemple vivant est /etc/pulse/daemon.conf (resample-method = speex-float-3)le nom décrit la syntaxe du fichier, et les paramètres de PulseAudio sont construits par paires "clé = valeur" - exactement ce à quoi ce format est destiné.

dovecot

Des paires key = value à plat à plat :

Des paires key = value à plat à plat : = avec des espaces facultatifs sépare le nom de la valeur, le commentaire est #, les enregistrements sont séparés par un saut de ligne, et le append par défaut est join. Il est fondé sur le format bind (décrit ci-dessous) et s'en distingue par deux choses : les enregistrements sont séparés les uns des autres par un saut de ligne, et non par ;``, и комментарий у него##, а не//.//.

Une particularité : le format a ses propres règles pour les directives d'inclusion - la normalisation des espaces réécrit !include_try в !include _try, après quoi la directive n'est plus reconnue. Pour de telles lignes, il vaut mieux substituer le texte prêt dans son ensemble plutôt que de les modifier par morceaux.

dhcp

Les enregistrements se suivent et sont séparés par ;, et le nom et la valeur sont séparés par un espace. Le commentaire est #, mais il n'est reconnu qu'en début de ligne, c'est pourquoi un dièse à l'intérieur d'une valeur est conservé comme partie de la valeur. Les options à plusieurs mots sont collées en un seul nom : option routers X; est lu par le format comme un seul enregistrement, et non comme trois mots séparés. Une ligne sans valeur (hostname) est un enregistrement légitime.

Il est fondé sur le format bind (décrit ci-dessous) et en hérite le séparateur d'enregistrements ;`` и разбиение по пробелу, меняя комментарий с//на#. Le ++append++ par défaut estjoin`.

Utilisé pour les fichiers dhcpcd.conf.

squid

Il se comporte comme procmail (ci-dessus), mais le nom et la valeur sont séparés par un espace simple, et non par = : un enregistrement ressemble à PermitRootLogin yes, sans signe égal. Le commentaire est #, les enregistrements sont séparés par un saut de ligne, et le append par défaut est join.

Utilisé pour sshd_config.d.

bind

Les enregistrements sont séparés par ;, et non par un saut de ligne : plusieurs enregistrements peuvent tenir sur une ligne. Le nom et la valeur sont séparés par des espaces, et le commentaire est //. Un enregistrement est modifié en le réécrivant entièrement avec le même nom.

Le format est dans le moteur et sert de base à apache, et par son intermédiaire à dovecot et dhcp (voir ci-dessus).

apache

Des lignes à plat name value, où le nom et la valeur sont séparés par un espace ou une tabulation ; le commentaire est #, et les enregistrements sont séparés par un saut de ligne. Il est fondé sur le format bind (ci-dessus) et s'en distingue par le commentaire et par le séparateur d'enregistrements, mais en contrepartie il comprend les constructions en bloc : la ligne d'en-tête d'un bloc et les directives imbriquées dedans sont lues comme une seule portée, et un nom de directive peut être constitué de plusieurs mots collés en un seul nom.

Le format est dans le moteur et sert de base à postfix, ainsi qu'à l'alias proftpd (voir ci-dessous).

XML

Les quatre formats de cette section ne travaillent pas avec des lignes mais avec un arbre d'éléments

Les quatre formats de cette section ne travaillent pas avec des lignes mais avec un arbre d'éléments : un enregistrement est trouvé par sa balise et les attributs de cette balise, et non par le texte de la ligne. D'où la règle principale - dans le modèle, il faut répéter les attributs qui identifient l'enregistrement (name, type et similaires) : sans eux, le nœud existant ne sera pas trouvé, et au lieu d'une mise à jour un second nœud dupliqué apparaît dans le fichier.

xml_xfce

Configurations Xfce : des propriétés de la forme <property name="…" type="…">, dont l'attribut value est mis à jour. Dans le modèle on répète le name et le type de la propriété voulue - sinon, au lieu de modifier la valeur, une nouvelle propriété est ajoutée.

xml_gconf_tree

Il est fondé sur le format xml_gconf (décrit ci-dessous), et la différence est dans l'endroit où le nœud est cherché : la correspondance se fait à n'importe quelle profondeur de l'arbre, et non seulement au niveau de la liste d'enregistrements. Appliquez-le quand la propriété voulue se trouve dans des groupes imbriqués. Les règles d'identification du nœud sont les mêmes que pour toute la section.

xml_gconf

Il est fondé sur le format xml_xfce (ci-dessus) et cherche de même le nœud par attributs, mais la valeur est stockée non dans un attribut mais dans un élément enfant : un enregistrement ressemble à <entry name="…" type="…"> avec un <stringvalue> imbriqué et similaires. L'attribut de service mtime est écarté avant la comparaison, afin qu'un écart de temps n'empêche pas de trouver l'enregistrement voulu.

xml_xfcepanel

Il se comporte comme xml_xfce, mais les nœuds <panel> sont appariés positionnellement, c'est-à-dire par l'ordre dans lequel ils se suivent, et non par attributs ; le nœud <items> est remplacé entièrement.

Le format est dans le moteur et prolonge xml_xfce pour la configuration des panneaux.

Formats structurels et de service

Ces formats sont nécessaires quand le contenu du fichier est décrit non par des paires "clé - valeur", mais par sa propre structure : le texte des modifications, une liste de paquets, un arbre de configuration ou une requête à une base.

patch

Le corps du modèle n'est pas une configuration mais des paires de balises : <reg> définit l'expression régulière, <text> - par quoi la remplacer.

# Calculate comment=# format=patch
<reg>^#(s[01])</reg>
<text>\1</text>

Seul ce format lit les paramètres d'en-tête multiline et dotall, qui changent les règles de recherche dans un texte à plusieurs lignes. Sans multiline, l'ancre ^ est liée au début de tout le fichier, et non de ses lignes : parmi des lignes également candidates, seule la première est remplacée. Si la modification doit toucher toutes les lignes commençant par #s0 ou #s1, ajoutez multiline dans l'en-tête. La valeur de append doit être patch - c'est aussi la valeur par défaut.

diff

Le corps du modèle est une sortie diff ordinaire, qui est appliquée par le programme externe /usr/bin/patch : vérifiez qu'il est installé dans le système. La valeur de append doit être patch.

Il est principalement utilisé dans 6_ac_install_patch avec des correctifs aux sources des paquets.

kernel

Le fichier .config du noyau du noyau : des lignes de la forme

Le fichier .config du noyau du noyau : des lignes de la forme CONFIG_…=y|m|n. Un paramètre désactivé s'écrit # CONFIG_… is not set, et cette forme est reconnue à part de la ligne avec valeur : un paramètre doit être désactivé précisément par cette forme.

dconf

Configuration du service utilisateur dconf : le chemin du schéma est défini par le paramètre d'en-tête dconf=/org/gnome/…, et la fusion s'exécute au nom de l'utilisateur via su avec dbus-run-session et /usr/bin/dconf. Physiquement, le fichier de configuration se trouve dans ~/.config/dconf/user (c'est une base SQLite) et est créé au premier démarrage de la session. La valeur de append doit être patch.

Il est utilisé dans la configuration du profil utilisateur.

backgrounds

Création d'images de fond : les dimensions sont indiquées dans le corps du modèle (640x480), l'image source est définie par le paramètre link=, et ImageMagick effectue le traitement (les paramètres convert= et stretch=). La valeur de append doit être patch.

json

Le corps du modèle est un JSON valide ; le format ne prend en charge aucun commentaire sous quelque forme que ce soit et n'a pas de caractère de commentaire. La fusion s'exécute uniquement au niveau supérieur : les clés de premier niveau absentes du modèle sont conservées, et un objet imbriqué est remplacé entièrement - donc tout ce qui est imbriqué et doit rester doit être réécrit dans le modèle. Le résultat est sérialisé avec un retrait de 4 espaces, il ne faut donc pas attendre une identité octet pour octet avec le fichier d'origine.

world

La liste /var/lib/portage/world : un atome par ligne, les slots et les substitutions sont autorisés (dev-db/postgresql:#-core.cl_core_pkg_slot-#).

contents

Il ne modifie pas du tout le texte des fichiers - ce format gère l'appartenance des fichiers aux paquets (les bases CONTENTS). La ligne définit un paquet et un chemin, et un masque est autorisé dans le chemin ; ! en début de ligne exclut le fichier de la composition du paquet. La valeur de append doit être patch.

Le format fonctionne pendant l'événement de fusion du paquet : tant que install.ac_install_merge est désactivé, le modèle ne sera pas fusionné, et l'outil l'indique par la ligne # Calculate ac_install_merge==on. Vous pouvez vérifier l'état de la variable avec la commande cl-core-variables-show.

# Calculate format=contents \
mergepkg(sys-apps/calculate-utils)!=&&ini(merge-calculate.utils)<3.6.0_alpha1
!sys-apps/openrc /etc/runlevels/default/net.*

sqlite

Le corps du modèle est un script SQL (PRAGMA, CREATE TABLE, INSERT), que le module standard sqlite3 exécute sur la base indiquée. La valeur de append doit être patch.

Des exemples sont dans 6_ac_desktop_profile, les bases libaccounts-glib.

Types intégrés et alias

raw

La valeur par défaut

La valeur par défaut : si format= n'est pas indiqué dans l'en-tête, le fichier est fusionné comme raw. Aucune fusion n'est effectuée : le fichier cible est réécrit entièrement (append=replace). Le paramètre ). Le paramètre comment= est nécessaire, avec le caractère de commentaire du fichier cible, pour que l'en-tête de service est nécessaire, avec le caractère de commentaire du fichier cible, pour que l'en-tête de service # Calculate ne casse pas sa syntaxe. ne casse pas sa syntaxe.

ldif

Le nom ldif figure dans la liste des formats "exécutables" du moteur et se rencontre dans l'ancienne documentation, mais aucun module de format de ce nom n'est fourni. C'est pourquoi un modèle avec format=ldif sans env= se termine par une erreur explicite d'en-tête : Paramètre d'en-tête de modèle incorrect : 'format=ldif' <file>. Pour les enregistrements d'annuaire, utilisez ldap (voir ci-dessus).

Ces deux cas sont faciles à confondre. Un modèle dont l'env= indique un module indisponible sur le système considéré (par exemple indique un module indisponible sur le système considéré (par exemple env=ldap sur une machine sans module LDAP configuré) est sur une machine sans module LDAP configuré) est ignoré sans aucun message - ni fichier, ni message. Il en va ainsi avec n'importe quelle valeur de sans aucun message - ni fichier, ni message. Il en va ainsi avec n'importe quelle valeur de format=, même une qui n'existe manifestement pas, même une qui n'existe manifestement pas :

Ces deux cas sont faciles à confondre. Un modèle dont l'env= indique un module indisponible sur le système considéré (par exemple indique un module indisponible sur le système considéré (par exemple env=ldap sur une machine sans module LDAP configuré) est sur une machine sans module LDAP configuré) est ignoré sans aucun message - ni fichier, ni message. Il en va ainsi avec n'importe quelle valeur de sans aucun message - ni fichier, ni message. Il en va ainsi avec n'importe quelle valeur de format=, même une qui n'existe manifestement pas, même une qui n'existe manifestement pas : format=nosuchthing avec env=ldap n'est pas fusionné non plus et ne produit rien. La raison est que la disponibilité du module est vérifiée avant l'analyse de l'en-tête. Ce sont donc deux maladies différentes : "format non pris en charge" donne toujours une erreur explicite d'en-tête, tandis que "rien ne s'est passé et il n'y a pas de sortie" est le signe d'un module indisponible, et il faut chercher dans env=, pas dans , pas dans format=..

Tous les modèles prêts de ce format se trouvent dans le répertoire 7_ac_server_ldif/ et portent env=ldap ou env=unix ; sur un système sans ces modules, ils ne créent aucun fichier et ne signalent rien, ce qui est le comportement normal de env=, et non un format cassé.

bin

Un fichier binaire. Il est déterminé automatiquement d'après le contenu (vérification du caractère binaire), et aucune mention séparée dans l'en-tête n'est nécessaire ; les modèles de ce type sont toujours append=replace.

proftpd

Un second nom pour le format apache : il se comporte exactement de la même façon et convient là où la configuration proftpd coïncide avec la syntaxe Apache.

Points communs de tous les formats

Le balisage du modèle - les substitutions #-variable-#, les blocs conditionnels #?condition# … #condition#, l'en-tête # Calculate … avec un retour à la ligne par \ - fonctionne pareil quel que soit le format : il est analysé avant même le choix du format. Le format n'affecte que le corps du fichier.

Une erreur à part de l'ancienne documentation : "pour un fichier vide, append=delete s'applique". Une telle valeur n'existe pas ; la suppression s'exécute avec append=remove, et un résultat "vide" est append=clear pour un fichier (mise à zéro) ou pour un répertoire (vidage du contenu).

Pour ceux qui lisent les sources du moteur

Cette section s'adresse à ceux qui lisent le code des utilitaires et non à ceux qui configurent des fichiers : elle rassemble les noms issus des sources que les descriptions ci-dessus ont remplacés par le comportement.

• Chaque format est une classe portant le même nom dans le module src/calculate/lib/format/<name>.py (26 modules), et format= dans l'en-tête est résolu ainsi : l'outil importe le module et y prend la classe du même nom. L'alias proftpd est défini par la table de prototypes newObjProt dans cl_template.py.
• La classe racine est TemplateFormat dans cl_template.py ; objShare dans generic.py est la base commune des fichiers à plat "clé = valeur" et, directement ou par une chaîne, des formats bind, apache, postfix, dovecot, dhcp, procmail, squid et openrc, ainsi que de samba avec ses descendants kde, ldap, compiz et plasma.
• Ce qui sépare le nom de la valeur est défini par l'expression régulière reSeparator ; ce qui sépare les enregistrements - par sepFields (d'habitude un saut de ligne, pour bind et dhcp c'est ;) ; le caractère de commentaire est l'attribut _comment ; l'en-tête de bloc de la famille ini et de apache est reHeader.
• reExecStr dans cl_template.py trouve la ligne de l'interpréteur (#!/…) dans le corps du modèle et la conserve ; la normalisation des espaces dans dovecot est faite par re.sub (d'où aussi la transformation de !include_try en !include _try).
• Le type de fichier issu de l'en-tête est renvoyé par _getType (raw par défaut), le mode d'ajout par _getAppend de la classe d'en-tête ; les paramètres d'en-tête eux-mêmes se trouvent dans HParams, et prevDictIni conserve les variables lues depuis le fichier de configuration pour la fonction ini().
• Les formats XML parcourent l'arbre via lxml ; les propriétés de nœuds comme nodeType appartiennent à cette bibliothèque, et non au moteur.

Voir aussi

• Comment choisir un format
• Syntaxe du modèle
• Qui fusionne les modèles et quand