.TH config 4 "kernel 10.5" "Ericsson AB" "Erlang Module Definition"
.SH NAME
config \- Configuration file
.SH DESCRIPTION
.PP
A \fIconfiguration file\fR contains values for configuration parameters for the applications in the system. The \fIerl\fR command-line argument \fI-config Name\fR tells the system to use data in the system configuration file \fIName.config\fR.

.PP
The erl command-line argument \fI-configfd\fR works the same way as the \fI-config\fR option but specifies a file descriptor to read configuration data from instead of a file.

.PP
The configuration data from configuration files and file descriptors are read in the same order as they are given on the command line. For example, \fIerl -config a -configfd 3 -config b -configfd 4\fR would cause the system to read configuration data in the following order \fIa.config\fR, file descriptor \fI3\fR, \fIb.config\fR, and file descriptor \fI4\fR. If a configuration parameter is specified more than once in the given files and file descriptors, the last one overrides the previous ones.

.PP
Configuration parameter values in a configuration file or file descriptor override the values in the application resource files (see \fIapp(4)\fR). The values in the configuration file are always overridden by command-line flags (see \fIerts:erl(1)\fR).

.PP
The value of a configuration parameter is retrieved by calling \fIapplication:get_env/1,2\fR.

.SS "File Syntax"

.PP
The configuration file is to be called \fIName.config\fR, where \fIName\fR is any name.

.PP
File \fI.config\fR contains a single Erlang term and has the following syntax:

.IP
.nf
[{Application1, [{Par11, Val11}, ...]},
 ...
 {ApplicationN, [{ParN1, ValN1}, ...]}].

.fi

Application = atom()
.RS 2
Application name.


.RE

Par = atom()
.RS 2
Name of a configuration parameter.


.RE

Val = term()
.RS 2
Value of a configuration parameter.


.RE

.SS "sys.config"

.PP
When starting Erlang in embedded mode, it is assumed that exactly one system configuration file is used, named \fIsys.config\fR. This file is to be located in \fI$ROOT/releases/Vsn\fR, where \fI$ROOT\fR is the Erlang/OTP root installation directory and \fIVsn\fR is the release version.

.PP
Release handling relies on this assumption. When installing a new release version, the new \fIsys.config\fR is read and used to update the application's configurations.

.PP
This means that specifying another \fI.config\fR file, or more \fI.config\fR files, leads to an inconsistent update of application configurations. There is, however, a way to point out other config files from a \fIsys.config\fR. How to do this is described in the next section.

.SS "Including Files from sys.config and -configfd Configurations"

.PP
There is a way to include other configuration files from a \fIsys.config\fR file and from a configuration that comes from a file descriptor that has been pointed out with the \fI-configfd\fR command-line argument.

.PP
The syntax for including files can be described by the Erlang type language like this:

.IP
.nf
[{Application, [{Par, Val}]} | IncludeFile].

.fi

IncludeFile = string()
.RS 2
Name of a 
\fI.config\fR file. The extension \fI.config\fR can be omitted. It is recommended to use absolute paths. If a relative path is used in a \fIsys.config\fR, \fIIncludeFile\fR is searched, first, relative to the \fIsys.config\fR directory, then relative to the current working directory of the emulator. If a relative path is used in a \fI-configfd\fR configuration, \fIIncludeFile\fR is searched, first, relative to the dictionary containing the boot script (see also the \fI-boot\fR command-line argument) for the emulator, then relative to the current working directory of the emulator. This makes it possible to use \fIsys.config\fR for pointing out other \fI.config\fR files in a release or in a node started manually using \fI-config\fR or \fI-configfd\fR with the same result whatever the current working directory is.

.RE

.PP
When traversing the contents of a \fIsys.config\fR or a \fI-configfd\fR configuration and a filename is encountered, its contents are read and merged with the result so far. When an application configuration tuple \fI{Application, Env}\fR is found, it is merged with the result so far. Merging means that new parameters are added and existing parameter values are overwritten.

.PP
\fIExample:\fR

.IP
.nf
sys.config:

["/home/user/myconfig1"
 {myapp,[{par1,val1},{par2,val2}]},
 "/home/user/myconfig2"].

myconfig1.config:

[{myapp,[{par0,val0},{par1,val0},{par2,val0}]}].

myconfig2.config:

[{myapp,[{par2,val3},{par3,val4}]}].

.fi

.PP
This yields the following environment for \fImyapp\fR:

.IP
.nf
[{par0,val0},{par1,val1},{par2,val3},{par3,val4}]

.fi

.PP
The run-time system will abort before staring up if an include file specified in \fIsys.config\fR or a \fI-configfd\fR configuration does not exist, or is erroneous. However, installing a new release version will not fail if there is an error while loading an include file, but an error message is returned and the erroneous file is ignored.

.SS "See Also"

.PP
\fIapp(4)\fR, \fIerts:erl(1)\fR, OTP Design Principles