Dlaczego / etc / fstab nie używa XML ani JSON?

To jest bardziej ogólne pytanie o Linuksa / programowanie, ale programuję od jakiegoś czasu i jestem przyzwyczajony do używania formatu takiego jak XML lub JSON na dowolnym pliku używanym do celów konfiguracyjnych.

Będąc nowym użytkownikiem Linuksa, zdałem sobie sprawę, że pierwszy plik konfiguracyjny, na który wpadłem ( /etc/fstab), używa jakiegoś formatu tabeli. Dlaczego więc nie XML lub JSON?

/etc/fstab jest znacznie starszy niż XML i JSON, a ponieważ używa go całkiem sporo programów, zmiana jego formatu byłaby koszmarem.

Poza tym /etc/fstabnależy to przeanalizować, zanim powstanie funkcjonalny system, ponieważ jest używany do montowania wszystkich niezbędnych systemów plików. Dlatego format /etc/fstabpowinien być tak prosty, jak to możliwe, ponieważ parser nie powinien zależeć od żadnych zewnętrznych bibliotek.

Analiza XML jest dość trudna i naprawdę chcesz tego uniknąć, jeśli nie możesz polegać na zewnętrznych bibliotekach. JSON jest nieco łatwiejszy, ale wciąż dość trudny.

Semantyka /etc/fstabjest dość prosta, nie zawiera żadnych drzewiastych struktur danych ani żadnych innych wymyślnych rzeczy. Wszystko czego potrzebujesz to rekordy składające się z sześciu wartości.

Wartości rozdzielone spacjami są do tego wystarczające i można je łatwo przeanalizować, nawet jeśli wszystko, co masz, to biblioteki C w standardzie C.

Nie ma więc powodu, aby używać JSON, XML lub czegoś podobnego.

Powinieneś naprawdę kiedyś przeczytać The Art of Unix Programming Erica Raymonda . Wydaje się, że przyjmujesz założenie, że projektanci Uniksa użyliby XML, /etc/fstabgdyby o tym wiedzieli. Wręcz przeciwnie, chociaż XML nie został specjalnie wynaleziony, byli dość świadomi jego podobnych poprzedników i celowo odrzucili je dla plików konfiguracyjnych takich jak /etc/fstab.

Cytując z jego podrozdziału na temat XML :

XML jest dobrze dostosowany do złożonych formatów danych (takich, w których oldschoolowa tradycja uniksowa używałaby formatu zwrotki podobnego do RFC-822), choć przesada w przypadku prostszych. Jest to szczególnie odpowiednie w przypadku formatów, które mają złożoną zagnieżdżoną lub rekurencyjną strukturę, której metaformat RFC 822 nie radzi sobie dobrze.

i dalej:

Najpoważniejszym problemem związanym z XML jest to, że nie działa on dobrze z tradycyjnymi narzędziami uniksowymi. Oprogramowanie, które chce czytać format XML, wymaga parsera XML; oznacza to nieporęczne, skomplikowane programy. Również sam XML jest dość nieporęczny; może być trudno zobaczyć dane pośród wszystkich znaczników.

Filozofia Uniksa polega na tym, aby konfiguracja była łatwa do pisania skryptami i czytelna dla człowieka, tam gdzie to możliwe. Powinieneś być w stanie przetwarzać pliki konfiguracyjne za pomocą narzędzi takich jak awk, grep, sed, tr i cut, a także łatwo parsować je w językach skryptowych bez dużych bibliotek. Jest to ogromny powód sukcesu Uniksa i nie należy go lekceważyć.

Chociaż Eric Raymond chwali XML za jego zdolność do obsługi „formatów o złożonej strukturze zagnieżdżonej lub rekurencyjnej”, z /etc/fstabpewnością nie ma takiej potrzeby, dlatego wybrano dla niego najprostszy możliwy format pliku.

Więc chociaż XML na pewno ma swoje zastosowania, możesz rozważyć, że niektórzy z najmądrzejszych programistów na świecie, którzy byli pionierami w tej dziedzinie, mogli wiedzieć, co robią. Być może XML nie zawsze najlepiej pasuje do twoich własnych plików konfiguracyjnych.

Głównym powodem, dla którego mogę teraz myśleć, jest:

• fstabPlik jest najczęściej używany przez mountkomendę
• Historia mountdowodzenia rozpoczęła się prawdopodobnie przed 1985 rokiem
• XML stał się Rekomendacją W3C 10 lutego 1998 r