21

This is more like a general Linux / programming question, but I've been programming for a while, and I'm used to using a format such as XML or JSON on any file which is used for configuration purposes.

Being new to Linux, I realized that the first configuration file I bumped into (/etc/fstab) uses some sort of table format. So why not XML or JSON?

Peter Mortensen
  • 884
jzeus
  • 329
  • 2
  • 7
  • 7
    What would happen if, say, we had XML parsing library in /usr/lib/libxml.so and /usr on separate partition? In order to parse /etc/fstab system would have to mount /usrz in order to loadlibxml, but to do so it would have to parse/etc/fstab` in order to know which filesystem to mount. In order to avoid this, XML parser would probably have to be part of kernel which doesn't sound like fantastic idea. – el.pescado - нет войне Mar 16 '14 at 15:11
  • 4
    @V0R73X, if you feel this question is a more general Linux question, there is another Stack site called UNIX & Linux Stack Exchange, unix.stackexchange.com. Both would probably be OK, and there are already answers here, but just throwing it out for the future. – trysis Mar 16 '14 at 16:22
  • 8
    XML and the like is not always the better format. A table is a table and should be stored as such. In fact some people think that XML is no good for anything https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV – alfC Mar 17 '14 at 05:53
  • 2
    JSON shouldn't be used for configuration files. It doesn't support comments, which are essential for explaining the configuration options, and for trying things out by commenting out parts of configuration. – artbristol Mar 18 '14 at 14:19
  • 2
    XML is a document transport format, not a configuration file format. – Matthew Ife Mar 18 '14 at 21:55

3 Answers3

82

/etc/fstab is much older than XML and JSON, and as quite a lot of programs use it changing its format would be a nightmare.

Besides this /etc/fstab needs to be parsed before there is a functional system as it is used to mount all essential file systems. Hence the format of /etc/fstab should be as simple as possible as the parser should not depend on any external libs.

Parsing XML is quite difficult and you really want to avoid it if you can't relay on external libs. JSON is a bit easier but still quite difficult.

The semantics of /etc/fstab are quite simple, they don't include any tree-like data structures or any other fancy stuff. All you need is records consisting of six values.

Whitepace-separated values are good enough for that, and they are easy to parse even if all you have is the C standard libs.

So there's just no reason to use JSON, XML or something similar.

Florian Diesch
  • 87,389
  • white separated fields are sufficient for what fstab needs to do. don't want to make things more complicated simply for the sake of doing it. – Michael Martinez Mar 16 '14 at 20:23
  • a CSV would be even simpler and easier – Sled Mar 17 '14 at 20:24
  • 3
    @ArtB why do you think changing the delimiter would change the complexity of parsing the file? – Dan Is Fiddling By Firelight Mar 17 '14 at 21:07
  • Depending on the rules for quoting, escaping etc. CSV could be a little bit easier to parse as the delimiter is always one char instead of the currently used variable length delimiter. But the current format allows for better human readability, which is an important value, too. – Florian Diesch Mar 18 '14 at 00:18
32

You should really read Eric Raymond's The Art of Unix Programming sometime. You seem to be making the assumption that the Unix designers would have used XML for /etc/fstab if they had known about it. On the contrary, although XML specifically had not been invented, they were quite aware of its similar predecessors, and deliberately rejected them for configuration files like /etc/fstab.

Quoting from his subsection on XML:

XML is well suited for complex data formats (the sort of things for which the old-school Unix tradition would use an RFC-822-like stanza format) though overkill for simpler ones. It is especially appropriate for formats that have a complex nested or recursive structure of the sort that the RFC 822 metaformat does not handle well.

and farther down:

The most serious problem with XML is that it doesn't play well with traditional Unix tools. Software that wants to read an XML format needs an XML parser; this means bulky, complicated programs. Also, XML is itself rather bulky; it can be difficult to see the data amidst all the markup.

The Unix philosophy is to make configuration easily scriptable and human readable wherever possible. You should be able to process config files with tools like awk, grep, sed, tr, and cut, and easily parse them in scripting languages without bulky libraries. This is a huge reason behind Unix's success and should not be underestimated.

Although Eric Raymond praises XML for its ability to handle "formats that have a complex nested or recursive structure," /etc/fstab certainly has no need for those, and therefore the simplest file format possible was chosen for it.

So although XML certainly has its uses, you might want to consider that some of the smartest programmers on the planet who pioneered the field might have known what they were doing. Perhaps XML isn't always the best fit for your own configuration files.

Karl Bielefeldt
  • 763
18

The main reason at which I can think now is:

Radu Rădeanu
  • 169,590
  • 4
    This answer doesn't actually show that the fstab file/format is as old as mount, which you seem to only imply. According to man fstab, "The ancestor of this fstab file format appeared in 4.0BSD." (the BSDs phrase it "The fstab file format appeared in 4.0BSD."). 4.0BSD was released in 1980. – Daniel Beck Mar 16 '14 at 14:34
  • @DanielBeck So, my guess was luckily true, before 1985. – Radu Rădeanu Mar 16 '14 at 14:42