Incomputing,configuration files (commonly known simply asconfig files) arefiles used to configure theparameters andinitial settings for somecomputer programs orapplications,server processes andoperating system settings.
Some applications provide tools to create, modify, and verify thesyntax of their configuration files; these sometimes have graphical interfaces. For other programs,system administrators may be expected to create and modify files by hand using a text editor, which is possible because many are human-editable plain text files. For server processes and operating-system settings, there is often no standard tool, but operating systems may provide their own graphical interfaces such asYaST or debconf.
Some computer programs only read their configuration files atstartup. Others periodically check the configuration files for changes. Users can instruct some programs to re-read the configuration files and apply the changes to the current process, or indeed to read arbitrary files as a configuration file. There are no definitive standards or strong conventions.
#) are used both as documentation and as a way to "disable" the setting.AcrossUnix-like operating systems many different configuration-file formats exist, with each application or service potentially having a unique format, but there is a strong tradition of them being in human-editable plain text, and a simplekey–value pair format is common. Filename extensions of.cnf,.conf,.cfg,.cf or.ini are often used.
Almost all formats allowcomments, in which case, individual settings can be disabled byprepending with the comment character. Often the default configuration files contain extensive internal documentation in the form of comments[1][2] andman files are also typically used to document the format and options available.
System-wide software often uses configuration files stored in/etc, while user applications often use a "dotfile" – a file or directory in the home directory prefixed with aperiod, whichin Unix hides the file or directory from casual listing. Since this causes pollution, newer user applications generally make their own folder in the.config directory, a standardized subdirectory of the home directory.
Some configuration files run a set of commands upon startup. A common convention is for such files to have "rc" in their name,[3] typically using the name of the program then an "(.)rc" suffix e.g. ".xinitrc", ".vimrc", ".bashrc", "xsane.rc". Seerun commands for further details.
By contrast,IBM'sAIX uses anObject Data Manager (ODM) database to store much of its system settings.
MS-DOS itself primarily relied on just one configuration file,CONFIG.SYS. This was a plain text file with simple key–value pairs (e.g.DEVICEHIGH=C:\DOS\ANSI.SYS) until MS-DOS 6, which introduced an INI-file style format. There was also a standard plain textbatch file namedAUTOEXEC.BAT that ran a series of commands onboot. Both these files were retained up toWindows 98SE, which still ran on top of MS-DOS.
An example CONFIG.SYS for MS-DOS 5:
DOS=HIGH,UMBDEVICE=C:\DOS\HIMEM.SYSDEVICE=C:\DOS\EMM386.EXE RAMDEVICEHIGH=C:\DOS\ANSI.SYSFILES=30SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
DOS applications used a wide variety of individual configuration files, most of them binary, proprietary and undocumented - and there were no common conventions or formats.[citation needed]
.png)
The earlyMicrosoft Windows family of operating systems heavily utilized plain-textINI files (from "initialization"). These served as the primary mechanism to configure the operating system and application features.[4] TheAPIs to read and write from these still exist in Windows, but after 1993, Microsoft began to steer developers away from using INI files and toward storing settings in theWindows Registry, a hierarchical database to store configuration settings, which was introduced that year withWindows NT.
TheProperty List is the standard configuration file format inmacOS (as well as iniOS,NeXTSTEP,GNUstep andCocoa applications). It uses thefilename extension.plist.
IBM'sOS/2 uses a binary format, also with a .INI suffix, but this differs from the Windows versions. It contains alist of lists of untyped key–value pairs.[5]Two files control system-wide settings: OS2.INI and OS2SYS.INI. Application developers can choose whether to use them or to create a specific file for their applications.
HarmonyOS andOpenHarmony-based operating systems uses “config.json” configuration file in the root directory of eachHAP application. It contains three modules such asapp,deviceConfig andModule. Theconfig.json file adheres to the JSON file format, where each entry comprises an attribute and its corresponding value. The sequence of attribute values is arbitrary, but each attribute must be unique and non-repetitive. The value assigned to each attribute aligns with the fundamental data types ofJSON. HarmonyOS’DevEco Studio provides two methods for editingconfig.json: the code editing view and the visual editing view. The `app` object holds the universal configuration details for the application, as demonstrated in theconfig.json configuration file of HarmonyOS's foundational application.DeviceConfig encompasses the configuration details for specific devices, including default, Phone, Tablet, PC, TV, Car, Wearable, liteWearable, and smartVision. The settings under the default label apply to all devices. If there are unique requirements for other devices, the settings under the respective device type label need to be configured. TheModule object carries the HAP package configuration details, the essential attributes that each Ability must define (such as package name, class name, type, and capabilities provided by Ability), along with the permissions the application needs to access the system or other protected sections of the application. TheMainAbility Indicates the name of HAP package’s entrance ability.[6]
A number of general-purposeserialization formats exist that can represent complex data structures in an easily stored format, and these are often used as a basis for configuration files, particularly inopen-source andplatform-neutral software applications and libraries. Thespecifications describing these formats are routinely made available to the public, thus increasing the availability ofparsers and emitters across programming languages.
Examples include:JSON,XML, andYAML.
| Format | Formal specs | Allowscomments | Syntax typing[8][9] |
|---|---|---|---|
| CUE[10] | Yes | Yes | Yes |
| INI | No | Yes | No |
| JSON | Yes[11] | No | Yes |
| TOML | Yes[12] | Yes | Yes |
| UCL | No[13] | Yes | Yes |
| YAML | Yes[14] | Yes | Yes |
| XML | Yes[15] | Yes | No |
true will be aBoolean while"true" will be astring – whereas in languages that do not allow syntax typing it will besemantics-based – e.g.true and"true" will be both recognizable as Booleans, whilemicrowave and"microwave" will be both recognizable as strings (this will require the parser to have some prior expectations about the type of a particular field, but this is often the case in configuration files).