Pourquoi / etc / fstab n'utilise-t-il pas XML ou JSON?

Cela ressemble plus à une question générale sur Linux / programmation, mais je programme depuis un certain temps et j'ai l'habitude d'utiliser un format tel que XML ou JSON sur n'importe quel fichier utilisé à des fins de configuration.

Étant nouveau sur Linux, j'ai réalisé que le premier fichier de configuration que j'ai rencontré ( /etc/fstab) utilise une sorte de format de tableau. Alors pourquoi pas XML ou JSON?

/etc/fstab est beaucoup plus ancien que XML et JSON, et comme beaucoup de programmes l'utilisent, changer son format serait un cauchemar.

En outre, cela /etc/fstabdoit être analysé avant qu'il n'y ait un système fonctionnel car il est utilisé pour monter tous les systèmes de fichiers essentiels. Par conséquent, le format de /etc/fstabdevrait être aussi simple que possible car l'analyseur ne devrait dépendre d'aucune bibliothèque externe.

L'analyse XML est assez difficile et vous voulez vraiment l'éviter si vous ne pouvez pas relayer sur des bibliothèques externes. JSON est un peu plus facile mais toujours assez difficile.

La sémantique de /etc/fstabest assez simple, elle n'inclut aucune structure de données arborescente ni aucun autre élément fantaisie. Tout ce dont vous avez besoin est des enregistrements composés de six valeurs.

Les valeurs séparées par des espaces sont suffisantes pour cela, et elles sont faciles à analyser même si vous ne disposez que des bibliothèques standard C.

Il n'y a donc aucune raison d'utiliser JSON, XML ou quelque chose de similaire.

Vous devriez vraiment lire The Art of Unix Programming d' Eric Raymond un jour . Vous semblez faire l'hypothèse que les concepteurs d'Unix auraient utilisé XML /etc/fstabs'ils l'avaient su. Au contraire, bien que XML spécifiquement n'ait pas été inventé, ils étaient tout à fait conscients de ses prédécesseurs similaires et les ont délibérément rejetés pour des fichiers de configuration comme /etc/fstab.

Citant de sa sous-section sur XML :

XML est bien adapté aux formats de données complexes (le genre de choses pour lesquelles la tradition Unix à l'ancienne utiliserait un format de strophe de type RFC-822), mais trop pour les plus simples. Il est particulièrement approprié pour les formats qui ont une structure imbriquée ou récursive complexe du type que le métaformat RFC 822 ne gère pas bien.

et plus bas:

Le problème le plus grave avec XML est qu'il ne fonctionne pas bien avec les outils Unix traditionnels. Un logiciel qui souhaite lire un format XML a besoin d'un analyseur XML; cela signifie des programmes volumineux et compliqués. De plus, XML est lui-même plutôt volumineux; il peut être difficile de voir les données au milieu de tout le balisage.

La philosophie Unix consiste à rendre la configuration facilement scriptable et lisible par l'homme dans la mesure du possible. Vous devriez pouvoir traiter les fichiers de configuration avec des outils tels que awk, grep, sed, tr et cut, et les analyser facilement dans des langages de script sans bibliothèques volumineuses. C'est une énorme raison derrière le succès d'Unix et ne doit pas être sous-estimée.

Bien qu'Eric Raymond vante XML pour sa capacité à gérer "les formats qui ont une structure imbriquée ou récursive complexe", /etc/fstabn'en a certainement pas besoin, et donc le format de fichier le plus simple possible a été choisi pour cela.

Ainsi, bien que XML ait certainement ses utilisations, vous voudrez peut-être considérer que certains des programmeurs les plus intelligents de la planète qui ont été les pionniers dans le domaine auraient pu savoir ce qu'ils faisaient. Peut-être que XML n'est pas toujours le mieux adapté à vos propres fichiers de configuration.

La principale raison pour laquelle je peux penser maintenant est:

• Le fstabfichier est le plus souvent utilisé par la mountcommande
• L'histoire du mountcommandement a commencé probablement avant 1985
• XML est devenu une recommandation du W3C le 10 février 1998