7

Many projects these days use more than one programming / scripting language, and in standard DRY tradition these should not have separate configuration files if they need the same information. After a small survey in /etc, it looks like a lot of incompatible syntaxes are used in Ubuntu:

  • varname=value - /etc/adduser.conf
  • varname: value - /etc/debconf.conf
  • varname = value - /etc/deluser.conf
  • $varname value /etc/insserv.conf
  • varname value - /etc/login.defs
  • set varname value - /etc/lftp.conf
  • [section]
        varname = value
    

    /etc/mke2fs.conf

  • section
        label varname value
        set varname value
    

    /etc/smartd.conf

As far as I can see, none of these are "Yaml or XML or JSON," (one of them is INI though). Which format would you recommend (and why) for a project which needs to provide simple values (debug = true, welcome = "Hello world!", threads = 4), arrays of simple values (servers = [dev, test, prod]), and values which refer to other variables (thread_msg = "Using $threads threads") to Bash, Perl and PHP?

l0b0
  • 51,350
  • AFAIK, the first 3 are basically the same. – tshepang Jul 12 '11 at 14:04
  • @l0b0 the first 3 are serialization formats which aren't configuration formats. I suggest using an actual configuration format like INI or Apache Style (Config::General in Perl). – xenoterracide Jul 12 '11 at 15:27
  • @l0b0 also that author lead his question on SO... and simply left out some of the options... while thinking like a programmer. While your OS designer's are thinking like admins and thus not making things a PITA for users. – xenoterracide Jul 12 '11 at 15:31
  • You understand that many Unix configuration files predates YAML, XML and JSON? – Thorbjørn Ravn Andersen Nov 04 '19 at 11:39
  • @ThorbjørnRavnAndersen I think that's pretty clear and not quite related to what the user is asking about. – Kusalananda Nov 04 '19 at 19:34
  • @Kusalananda That explains why that none of the formats currently in vogue is used for something that was designed before they existed. As for now, it seems that new projects tend to select YAML - a bit more expressive than plain JSON and a lot less verbose than XML. – Thorbjørn Ravn Andersen Nov 05 '19 at 09:36

2 Answers2

3

I would use a format, which can be sourced by bash as is, because in bash it isn't easy to read, parse and execute other formats, while Perl is more or less a language, written for such tasks, and in PHP it should be easy too.

user unknown
  • 10,482
  • That's fine for simple values, but Bash doesn't have many common types such as decimal or floating point numbers, and you can't nest collections. – l0b0 Nov 04 '19 at 19:35
  • @l0b0: I don't really understand your comment. My intention was to source the whole document in bash, if it is to be used from bash, so if you can't nest collections or want to use floating points, you might not be using bash and for using PHP or Perl, using the bash-format isn't my suggestion. Maybe I should formulate my answer more clearly. – user unknown Nov 05 '19 at 16:56
3

The first 3 are serialization formats which aren't configuration formats. These formats are easy for machines to read and write but not as easy for humans to read and write. Do not use them for configuration. Your users will likely hate you for it.

Also some of these files are simply NAME value pairs. Others might not really be configuration files but shell files, meaning they can basically be sourced by a shell for processing.

I suggest using an actual configuration format like INI or Apache Style (Config::General in Perl)

Config::Any is a good choice of perl module for loading a config, because it allows the user to essentially pick the format of their choice.

xenoterracide
  • 59,188
  • 74
  • 187
  • 252