In an Linux application I don't want to use "my own" configuration parser, but use the one which (should be?) is already available. Simple to keep the maintenance of the application config simple and not adding extra libraries.

  • 2
    I don't think there's a standard. The closest you get is probably dumb ini-files, which hardly requires a sophisticated parser.
    – Clearer
    May 1 '18 at 11:48
  • @Clearer Except that some INI-files support groupings in sections and cross references between settings etc.
    – Kusalananda
    Dec 12 '18 at 21:38
  • @Kusalananda And then you wouldn't have an INI-file anymore, but just something that resembles it.
    – Clearer
    Dec 13 '18 at 13:16

There really isn't a 'standard' configuration parser library. If you peruse through /etc, you will find some combination of:

  • XML config
  • Windows INI style config
  • Basic KEY=VALUE config
  • JSON (mostly seen with web applications).
  • YAML (mostly seen with newer stuff, especially if written in Python).
  • Things that look like JSON or YAML or XML, but aren't (see for example configuration for Nginx (looks like JSON, but isn't), Apache (looks like XML, but isn't), and Unbound (looks like YAML, but isn't).
  • Various shell languages.
  • Various things that look like shell languages but technically aren't.
  • Source snippets in various scripting languages.
  • Possibly other things I haven't thought of.

As far as what to use with your app:

  • Please for the love of all things holy avoid XML. It's unnecessarily verbose, very complicated to parse (and thus takes a long time and lots of memory), and brings a number of security issues. It's also non-trivial to get the proper balance between elements and attributes, and you will usually end up regretting choices made regarding that at some point later. The only real advantage here is that you're pretty much guaranteed to have a working XML parser on any system you come across.
  • Windows style INI files are generally a safe bet, though they limit the complexity of your config structures. Lots of libraries exist for this, and your system probably already has at least one. They aren't as prevalent on Linux (classic config files are traditionally KEY=VALUE pairs without section headers), but they're still widely used, and they're easy to understand.
  • Basic KEY=VALUE pairs (one per line ideally) are so trivial to parse that you don't even need a library for it, but are very limited in what they can do.
  • JSON is safe and easy to parse, is widely supported (pretty much every major language has at least one parser these days), and supports arbitrary nesting of config structures. However, it doesn't support comments (some parsers might, but the results won't be interoperable), which is not great for files designed to be edited with a text editor.
  • YAML is my personal favorite, it's reasonably safe and easy to parse, looks very natural to most people, supports comments, and has very minimal overhead. The only big thing here is that indentation really matters, as it accounts for about 80% of the syntax, which combined with the fact that YAML requires spaces for indentation (no tabs), can make it a bit of a hassle to work with if you don't have a good editor.
  • If you're using a scripting language, you might consider using source snippets for config, but be very careful doing this. Unless you're very careful about how you parse them, you're pretty much letting users do arbitrary things to your internal logic if they want to, which is a customer support nightmare (you will eventually get people complaining that you broke their config, which happened to include stuff poking at core program internals that you changed).
  • Thanks for this extensive rundown on all available/used approaches to configuration files. It also makes me realise that my question can't be answered, since there simply seems to be no standard or canonical configuration format.
    – nanitous
    Apr 27 '19 at 14:02

One standard configuration parser that comes to mind is shell code used to set environment variables.

If your software is started by something that does:

#! /bin/sh -
set -o allexport
for conf in /etc/default/mysoft ~/.config/mysoft.conf; do
  [ -f "$conf" ] && [ -r "$conf" ] && . "$conf"
unset -v conf
exec mysoft "$@"

Then your users can create some ~/.config/mysoft.conf with content like:

# even using shell code to set the values:
MYSOFT_MAX_COLUMNS=$((${COLUMNS:-$(tput cols)} / 2))

and mysoft can query these values with getenv("MYSOFT_TUNABLE") or corresponding API in the language it's written in.

That's limited to flat key=value where value is limited to strings of non-NUL characters though. If you need more complex data structures, you can look at JSON or XML for which most languages have one or more parsing libraries.

For software written in interpreted languages (like php, perl, python...), a common simple and very flexible approach is simply to write configuration files as source files in those languages.

For instance, for perl, create a ~/.config/mysoft/conf.pl as:

%conf = (
  string_param => "string",
  list_param => [1, 2],
  complex_param => { foo => "bar", bar => "baz" }

Those are also trivial to generate programmatically.

For sh, you can just use export -p:

setenv("MYSOFT_TUNABLE", "bar");
system("export -p MYSOFT_TUNABLE MYSOFT_MAX_COLUMS > ~/.conf/mysoft.conf");

Or with perl:

use Data::Dumper;
print Data::Dumper->Dump([\%conf], ["*conf"]);
  • Thanks for the idea, but I wanted to be able to update such a configuration format programmatically this and your suggestion would require such configuration to be parsed. That is not what I've had in mind. (Save from including text files with simple "set" commands)
    – nanitous
    Apr 27 '19 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.