4 ms·

> A common configuration format for all of them Easier said than done. Some applications don't require the complexity of JSON/TOML, and it's best for them to u

> A common configuration format for all of them Easier said than done. Some applications don't require the complexity of JSON/TOML, and it's best for them to use a simple and regular language to make tools like cut/sed easier to use. Others naturally lend themselves to scripted configurations, in which case a full-fledged scripting language makes sense. Others yet require rich object configuration specifications, in which case JSON/TOML/YAML makes sense. I don't think there can be one configuration file to rule them all.

coldtea 10y ago
>Easier said than done. Some applications don't require the complexity of JSON/TOML, and it's best for them to use a simple and regular language to make tools like cut/sed easier to use. cut/sed are usually used for the program's output, not their configuration files. And if there was that common configuration format, you wouldn't need cut/sed or any such crude tool for the configuration files either, you could have a universal conf-edit tool, that could read the raw config files and output the configuration in whatever formal (XML, JSON etc) and convert it back in, search for specific entries, set specific settings, etc. >Others yet require rich object configuration specifications, in which case JSON/TOML/YAML makes sense. I don't think there can be one configuration file to rule them all. Even so, there can be one configuration language for an awful lot of programs, that don't have those special needs, and there isn't one. Instead it's a mishmash of every kind of custom parser.