NAME
config - Configuration file.
DESCRIPTION
A configuration file contains values for configuration parameters for
the applications in the system. The erl command line argument -config
Name tells the system to use data in the system configuration file
Name.config.
Configuration parameter values in the configuration file will override
the values in the application resource files (see app(4)). The values
in the configuration file can be overridden by command line flags (see
erl(1)).
The value of a configuration parameter is retrieved by calling
application:get_env/1,2.
FILE SYNTAX
The configuration file should be called Name.config where Name is an
arbitrary name.
The .config file contains one single Erlang term. The file has the
following syntax:
[{Application1, [{Par11, Val11}, ..]},
..
{ApplicationN, [{ParN1, ValN1}, ..]}].
* Application = atom() is the name of the application. .br .br
* Par = atom() is the name of a configuration parameter. .br .br
* Val = term() is the value of a configuration parameter. .br .br
SYS.CONFIG
When starting Erlang in embedded mode, it is assumed that exactly one
system configuration file is used, named sys.config. This file should
be located in $ROOT/releases/Vsn, where $ROOT is the Erlang/OTP root
installation directory and Vsn is the release version.
Release handling relies on this assumption. When installing a new
release version, the new sys.config is read and used to update the
application configurations.
This means that specifying another, or additional, .config files would
lead to inconsistent update of application configurations. Therefore,
in Erlang 5.4/OTP R10B, the syntax of sys.config was extended to allow
pointing out other .config files:
[{Application, [{Par, Val}]} | File].
* File = string() is the name of another .config file. The extension
.config may be omitted. It is recommended to use absolute paths. A
relative path is relative the current working directory of the
emulator. .br .br
When traversing the contents of sys.config and a filename is
encountered, its contents are read and merged with the result so far.
When an application configuration tuple {Application, Env} is found, it
is merged with the result so far. Merging means that new parameters are
added and existing parameter values overwritten. Example:
sys.config:
[{myapp,[{par1,val1},{par2,val2}]},
"/home/user/myconfig"].
myconfig.config:
[{myapp,[{par2,val3},{par3,val4}]}].
This will yield the following environment for myapp:
[{par1,val1},{par2,val3},{par3,val4}]
The behaviour if a file specified in sys.config does not exist or is
erroneous in some other way, is backwards compatible. Starting the
runtime system will fail. Installing a new release version will not
fail, but an error message is given and the erroneous file is ignored.
SEE ALSO
app(4), erl(1), OTP Design Principles