Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

config(5) [linux man page]

config(5)							       Files								 config(5)

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(5) ). The val- ues 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. * Par = atom() is the name of a configuration parameter. * Val = term() is the value of a configuration parameter. 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 appli- cation configurations. This means that specifying another, or additional, .config files would lead to inconsistent update of application configurations. There- fore, 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. 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(5) , erl(1) , OTP Design Principles Ericsson AB kernel 2.14.3 config(5)

Check Out this Related Man Page

rc.config(4)						     Kernel Interfaces Manual						      rc.config(4)

NAME
rc.config, rc.config.d - files containing system configuration information SYNOPSIS
DESCRIPTION
The system configuration used at startup is contained in files within the directory The file sources all of the files within and and exports their contents to the environment. /etc/rc.config The file is a script that sources all of the scripts, and also sources To read the configuration definitions, only this file need be sourced. This file is sourced by whenever it is run, such as when the command is run to transition between run states. Each file that exists in is sourced, without regard to which startup scripts are to be executed. /etc/rc.config.d The configuration information is structured as a directory of files, rather than as a single file containing the same information. This allows developers to create and manage their own configuration files here, without the complications of shared ownership and access of a common file. /etc/rc.config.d/* Files This is where files containing configuration variable assignments are located. Configuration scripts must be written to be read by the POSIX shell, and not the Bourne shell, or In some cases, these files must also be read and possibly modified by control scripts or the sam program. See sd(4) and sam(1M). For this reason, each variable definition must appear on a separate line, with the syntax: No trailing comments may appear on a variable definition line. Comment statements must be on separate lines, with the comment character in column one. This example shows the required syntax for configuration files: Configuration variables may be declared as array parameters when describing multiple instances of the variable configuration. For example, a system may contain two network interfaces, each having a unique IP address and subnet mask (see ifconfig(1M)). An example of such a dec- laration is as follows: Note that there must be no requirements on the order of the files sourced. This means configuration files must not refer to variables defined in other configuration files, since there is no guarantee that the variable being referenced is currently defined. There is no protection against environment variable namespace collision in these configuration files. Programmers must take care to avoid such prob- lems. /etc/TIMEZONE The file contains the definition of the environment variable. This file is required by POSIX. It is sourced by at the same time the files are sourced. SEE ALSO
rc(1M). rc.config(4)
Man Page