C'est bien dommage que les plist fassent peur comme ça, les plist (property lists) ont pas mal d'avantages.
C'est à la base un format abstrait, qui peut être indifféremment écrit sous forme binaire, XML ou JSON (avec quelques limites sur le format JSON cependant).
- le format est bien documenté (bon, ok, il faut dire qu'il n'est pas franchement compliqué…).
- il y a des utilitaires pour le convertir d'une représentation à l'autre (du binaire à l'XML, par exemple), pour l'éditer à la main
- des libs existent dans différents langages (par exemple Python, ça fait même partie de la lib standard) pour lire et écrire des plist
- un utilitaire en ligne de commande (defaults) permet de modifier certaines valeurs
- il existe des utilitaires graphiques pour éditer plus facilement le contenu (quand le XML ou le JSON est un peu rébarbatif)
Au final, on se retrouve avec des fichiers de configuration super pratiques, vu que :
- pas de problème de syntaxe différente entre deux applications (ah, la joie des différences entre espaces et tab, surtout avec un éditeur configuré pour remplacer l'un par l'autre)
- besoin de lire la configuration d'un autre programme depuis son propre logiciel ? pas de parseur exotique à réécrire !
- besoin de changer une configuration depuis un script ? la commande defaults le permet sans souci.
Il manquerait peut-être un éditeur en ligne de commande, mais ça ne doit pas être très compliqué à coder.
Tous les fichiers de configuration (ou assimilables) sur OS X sont des plist (fichiers de conf, descriptifs d'une application, préférences de l'utilisateur, démons lancés par launchd, …), sauf les applis UNIX pures, naturellement.
Certes, cela ne permet pas les commentaires dans le fichier de configuration (à ma connaissance). J'imagine que l'idée pourrait être améliorée assez facilement.
Je ne dis pas que c'est la solution parfaite, simplement qu'avoir une seule syntaxe et qui soit utilisable via le shell, dans un éditeur ou via n'importe quel langage de prog est vraiment très pratique.
[^] # Re: Et pour en remettre une couche
Posté par flan (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
C'est bien dommage que les plist fassent peur comme ça, les plist (property lists) ont pas mal d'avantages.
C'est à la base un format abstrait, qui peut être indifféremment écrit sous forme binaire, XML ou JSON (avec quelques limites sur le format JSON cependant).
- le format est bien documenté (bon, ok, il faut dire qu'il n'est pas franchement compliqué…).
- il y a des utilitaires pour le convertir d'une représentation à l'autre (du binaire à l'XML, par exemple), pour l'éditer à la main
- des libs existent dans différents langages (par exemple Python, ça fait même partie de la lib standard) pour lire et écrire des plist
- un utilitaire en ligne de commande (defaults) permet de modifier certaines valeurs
- il existe des utilitaires graphiques pour éditer plus facilement le contenu (quand le XML ou le JSON est un peu rébarbatif)
Au final, on se retrouve avec des fichiers de configuration super pratiques, vu que :
- pas de problème de syntaxe différente entre deux applications (ah, la joie des différences entre espaces et tab, surtout avec un éditeur configuré pour remplacer l'un par l'autre)
- besoin de lire la configuration d'un autre programme depuis son propre logiciel ? pas de parseur exotique à réécrire !
- besoin de changer une configuration depuis un script ? la commande defaults le permet sans souci.
Il manquerait peut-être un éditeur en ligne de commande, mais ça ne doit pas être très compliqué à coder.
Tous les fichiers de configuration (ou assimilables) sur OS X sont des plist (fichiers de conf, descriptifs d'une application, préférences de l'utilisateur, démons lancés par launchd, …), sauf les applis UNIX pures, naturellement.
Certes, cela ne permet pas les commentaires dans le fichier de configuration (à ma connaissance). J'imagine que l'idée pourrait être améliorée assez facilement.
Je ne dis pas que c'est la solution parfaite, simplement qu'avoir une seule syntaxe et qui soit utilisable via le shell, dans un éditeur ou via n'importe quel langage de prog est vraiment très pratique.