Configuration file: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
No edit summary
Tags: Reverted categories removed references removed Mobile edit Mobile web edit
→‎Configuration files and operating systems: HarmonyOS and OpenHarmony-based operating systems
 
(21 intermediate revisions by 19 users not shown)
Line 1: Line 1:
{{Short description|Software file used to configure the initial settings for a computer program}}
{{Short description|Software file used to configure the initial settings for a computer program}}
{{Redirect|rc file|Microsoft Windows resource scripts|Resource (Windows)}}
{{Redirect|rc file|resource scripts|Resource (Windows)}}


In [[computing]], '''configuration files''' (commonly known simply as '''config files''') are [[computer file|file]]s used to configure the [[Parameter (computer programming)|parameters]] and [[Initialization (programming)|initial settings]] for some [[computer program]]s. They are used for user [[application software|applications]], [[Server (computing)|server processes]] and [[operating system]] settings.
In [[computing]], '''configuration files''' (commonly known simply as '''config files''') are [[computer file|file]]s used to configure the [[Parameter (computer programming)|parameters]] and [[Initialization (programming)|initial settings]] for some [[computer program]]s or [[application software|applications]], [[Server (computing)|server processes]] and [[operating system]] settings.


Some applications provide tools to create, modify, and verify the [[syntax]] of their configuration files; these sometimes have graphical interfaces. For other programs, [[system administrator]]s 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 as [[YaST]] or debconf.
Some applications provide tools to create, modify, and verify the [[syntax]] of their configuration files; these sometimes have graphical interfaces. For other programs, [[system administrator]]s 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 as [[YaST]] or debconf.
Line 8: Line 8:
Some computer programs only read their configuration files at [[Booting|startup]]. 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.
Some computer programs only read their configuration files at [[Booting|startup]]. 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.


[[File:Gnu grub config file.png|400px|thumb|A configuration file for [[GNU GRUB]] being edited. Comments (the lines beginning with a '<code>#</code>') are used both as documentation and as a way to "disable" the setting.]]
[[File:Gnu grub config file.png|400px|thumb|A configuration file for [[GNU GRUB]] being edited. Comments (the lines beginning with a <code>#</code>) are used both as documentation and as a way to "disable" the setting.]]


==Configuration files and operating systems==
==Configuration files and operating systems==
Line 15: Line 15:
Across [[Operating system#Unix and Unix-like operating systems|Unix-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 simple [[attribute–value pair|key–value pair]] format is common. Filename extensions of <code>.cnf</code>, <code>.conf</code>, <code>.cfg</code>, <code>.cf</code> or <code>.ini</code> are often used.
Across [[Operating system#Unix and Unix-like operating systems|Unix-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 simple [[attribute–value pair|key–value pair]] format is common. Filename extensions of <code>.cnf</code>, <code>.conf</code>, <code>.cfg</code>, <code>.cf</code> or <code>.ini</code> are often used.


Almost all formats allow [[Comment (computer programming)|comments]], in which case, individual settings can be disabled by [[comment out|prepending with the comment character]]. Often the default configuration files contain extensive internal documentation in the form of comments<ref name=":0">https://opensource.apple.com/source/postfix/postfix-174.2/Postfix.Config/main.cf.default. {{Dead link|date=February 2022}}</ref><ref name=":1">http://opensource.apple.com/source/apache/apache-769/httpd.conf. {{Dead link|date=February 2022}}</ref> and [[man file]]s are also typically used to document the format and options available.
Almost all formats allow [[Comment (computer programming)|comments]], in which case, individual settings can be disabled by [[comment out|prepending with the comment character]]. Often the default configuration files contain extensive internal documentation in the form of comments<ref name=":0">https://opensource.apple.com/source/postfix/postfix-174.2/Postfix.Config/main.cf.default. {{Webarchive|url=https://web.archive.org/web/20170803053000/https://opensource.apple.com/source/postfix/postfix-174.2/Postfix.Config/main.cf.default |date=2017-08-03 }}</ref><ref name=":1">http://opensource.apple.com/source/apache/apache-769/httpd.conf. {{Webarchive|url=https://web.archive.org/web/20200801023500/https://opensource.apple.com/source/apache/apache-769/httpd.conf |date=2020-08-01 }}</ref> and [[man file]]s are also typically used to document the format and options available.


System-wide software often uses configuration files stored in <code>[[/etc]]</code>, while user applications often use a "[[dotfile]]" – a file or directory in the home directory prefixed with a [[full stop|period]], which [[Hidden file and hidden directory#Unix and Unix-like environments|in Unix hides the file or directory]] from casual listing.
System-wide software often uses configuration files stored in <code>[[/etc]]</code>, while user applications often use a "[[dotfile]]" – a file or directory in the home directory prefixed with a [[full stop|period]], which [[Hidden file and hidden directory#Unix and Unix-like environments|in Unix hides the file or directory]] from casual listing. Since this causes pollution, newer user applications generally make their own folder in the <code>.config</code> 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 "<code>rc</code>" in their name,<ref name="autogenerated1">{{cite web|url=http://www.catb.org/jargon/html/R/rc-file.html |title=rc file |publisher=Catb.org |access-date=2012-02-29}}</ref> typically using the name of the program then an "<code>(.)rc</code>" suffix e.g. "<code>.xinitrc</code>", "<code>.vimrc</code>", "<code>.bashrc</code>", "<code>xsane.rc</code>". See [[run commands]] for further details.
Some configuration files run a set of commands upon startup. A common convention is for such files to have "<code>rc</code>" in their name,<ref name="autogenerated1">{{cite web|url=http://www.catb.org/jargon/html/R/rc-file.html |title=rc file |publisher=Catb.org |access-date=2012-02-29}}</ref> typically using the name of the program then an "<code>(.)rc</code>" suffix e.g. "<code>.xinitrc</code>", "<code>.vimrc</code>", "<code>.bashrc</code>", "<code>xsane.rc</code>". See [[run commands]] for further details.
Line 27: Line 27:


An example CONFIG.SYS for MS-DOS 5:
An example CONFIG.SYS for MS-DOS 5:
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini" line="1">
DOS=HIGH,UMB
DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\HIMEM.SYS
Line 40: Line 40:
===Microsoft Windows===
===Microsoft Windows===
[[File:Regedit (Wine).png|thumb|right|The REGEDIT application being used to edit Windows Registry data]]
[[File:Regedit (Wine).png|thumb|right|The REGEDIT application being used to edit Windows Registry data]]
The early [[Microsoft Windows]] family of operating systems heavily utilized plain-text [[INI file]]s (from "initialization"). These served as the primary mechanism to configure the operating system and application features. The [[API]]s to read and write fhierarchical database to store configur the [[filename extension]] <code>.plist</code>.
The early [[Microsoft Windows]] family of operating systems heavily utilized plain-text [[INI file]]s (from "initialization"). These served as the primary mechanism to configure the operating system and application features.<ref>[https://www.microsoft.com/resources/documentation/windowsnt/4/workstation/reskit/en-us/26_ini.mspx Microsoft: Windows NT Workstation Resource Kit].</ref> The [[API]]s 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 the [[Windows Registry]], a hierarchical database to store configuration settings, which was introduced that year with [[Windows NT]].

===macOS===
The [[Property list|Property List]] is the standard configuration file format in [[macOS]] (as well as in [[IOS (Apple)|iOS]], [[NeXTSTEP]], [[GNUstep]] and [[Cocoa (API)|Cocoa]] applications). It uses the [[filename extension]] <code>.plist</code>.


===IBM OS/2===
===IBM OS/2===
IBM's [[OS/2]] uses a binary format, also wdiffers from the Windows versions. It contains a [[list (data structure)|list]] of lists of untyped key–value pairs.<ref name="voice">''[http://www.os2voice.org/VNL/past_issues/VNL0904H/vnewsf4.htm The OS/2 INI Files]'' by James J. Weinkam.</ref>
IBM's [[OS/2]] uses a binary format, also with a .INI suffix, but this differs from the Windows versions. It contains a [[list (data structure)|list]] of lists of untyped key–value pairs.<ref name="voice">''[http://www.os2voice.org/VNL/past_issues/VNL0904H/vnewsf4.htm The OS/2 INI Files]'' by James J. Weinkam.</ref>
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.
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 and OpenHarmony operating systems ===
[[HarmonyOS]] and [[OpenHarmony]]-based operating systems uses “config.json” configuration file in the root directory of each [[App (file format)|HAP]] application. It contains three modules such as <code>app</code>, <code>deviceConfig</code> and <code>Module</code>. The <code>config.json</code> 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 of [[JSON]]. HarmonyOS’ [[DevEco Studio]] provides two methods for editing <code>config.json</code>: the code editing view and the visual editing view. The `app` object holds the universal configuration details for the application, as demonstrated in the <code>config.json</code> configuration file of HarmonyOS's foundational application. <code>DeviceConfig</code> 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. The <code>Module</code> 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. The <code>MainAbility</code> Indicates the name of HAP package’s entrance ability.<ref>{{cite web |last1=Evans |first1=Melissa |title=HarmonyOS (Hongmeng) — config.json |url=https://www.mo4tech.com/harmonyos-hongmeng-config-json.html |website=Mo4Tech |publisher=Mo4Tech |access-date=24 March 2024}}</ref>


==Serialization formats==
==Serialization formats==
A number of general-purpose [[serialization]] 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 in [[Open-source software|open-source]] and [[Cross-platform|platform-neutral]] software applications and libraries. The [[specification]]s describing these formats are routinely made available to the public, thus increasing the availability of [[parser]]s and emitters<!-- could think of these as "code generators" but there's no suitable article available that captures this concept properly; the page "Comparison of code generation tools" would benefit from such a page, too --> across programminlanguage)|Java]]
A number of general-purpose [[serialization]] 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 in [[Open-source software|open-source]] and [[Cross-platform|platform-neutral]] software applications and libraries. The [[specification]]s describing these formats are routinely made available to the public, thus increasing the availability of [[parser]]s and emitters<!-- could think of these as "code generators" but there's no suitable article available that captures this concept properly; the page "Comparison of code generation tools" would benefit from such a page, too --> across programming languages.
* [[HOCON]and data structures
Examples include: [[JSON]], [[XML]], and [[YAML]].
* [[Run commands]], which explains the h file format

== Comparison ==
{| class="wikitable"
|+Format comparison<ref>{{Citation |title=TOML |date=2023-01-15 |url=https://github.com/toml-lang/toml |publisher=TOML |access-date=2023-01-15}}</ref>
! scope="col" |[[File format|Format]]
! scope="col" |Formal specs
! scope="col" |Allows [[Comment (computer programming)|comments]]
! scope="col" |Syntax typing{{refn|Syntax typing refers to the use of [[Syntax (programming languages)|syntax]] to designate [[Data type|data types]]. In languages that allow syntax typing, type declaration will be syntax-based – e.g. <code>true</code> will be a [[Boolean data type|boolean]] while <code>"true"</code> will be a [[String (computer science)|string]] – whereas in languages that do not allow syntax typing it will be [[Semantics (computer science)|semantics]]-based – e.g. <code>true</code> and <code>"true"</code> will be both recognizable as booleans, while <code>microwave</code> and <code>"microwave"</code> 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).}}{{refn|Opinions on whether syntax typing in configuration formats is a good or a bad feature vary among authors. with some considering it a disadvantage (see for example [https://hitchdev.com/strictyaml/why-not/toml/#4-syntax-typing What is wrong with TOML § Syntax typing]) and others favoring it.}}
|-
|CUE<ref>{{cite web |title=About {{!}} CUE |url=https://cuelang.org/docs/about/ |access-date=October 6, 2022}}</ref>|| {{Yes}} || {{Yes}} || {{good|Yes}}
|-
|[[INI file|INI]]|| {{No}} || {{Yes}} || {{good|No}}
|-
|[[JSON]]|| {{Yes}}<ref>{{Cite web|url=https://datatracker.ietf.org/doc/html/rfc8259|title=The JavaScript Object Notation (JSON) Data Interchange Format}}</ref> || {{No}} || {{good|Yes}}
|-
|[[TOML]]|| {{Yes}}<ref>{{Cite web|url=https://toml.io/en/v1.0.0|title=TOML Specification}}</ref> || {{Yes}} || {{good|Yes}}
|-
|[[YAML]]|| {{Yes}}<ref>{{Cite web|url=https://yaml.org/spec|title=YAML™ Specification Index}}</ref> || {{Yes}} || {{good|Yes}}
|-
|[[XML]]|| {{Yes}}<ref>{{Cite web|url=https://www.w3.org/TR/xml/|title=Extensible Markup Language (XML) 1.0 (Fifth Edition)}}</ref> || {{Yes}} || {{good|No}}
|}

==See also==
* [[.properties]], a file extension mainly used in [[Java (programming language)|Java]]
* [[HOCON]], a superset of .properties and JSON
* [[INI file]], a common configuration file format
* [[JSON]], with support for complex data types and data structures
* [[Run commands]], which explains the historical origin of the "rc" suffix
* [[TOML]], a formally-specified configuration file format
* [[YAML]], with support for complex data types and structures
* [[YAML]], with support for complex data types and structures


==References==
==Ref
<references />

{{DEFAULTSORT:Configuration File}}
<!--[[Category:Computer data]] deleted. That cat is about data in general, not some particular application's data -->
[[Category:Configuration files| ]]

Latest revision as of 08:43, 24 March 2024

In computing, configuration files (commonly known simply as config files) are files used to configure the parameters and initial settings for some computer programs or applications, server processes and operating system settings.

Some applications provide tools to create, modify, and verify the syntax 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 as YaST or debconf.

Some computer programs only read their configuration files at startup. 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.

A configuration file for GNU GRUB being edited. Comments (the lines beginning with a #) are used both as documentation and as a way to "disable" the setting.

Configuration files and operating systems[edit]

Unix and Unix-like operating systems[edit]

Across Unix-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 simple key–value pair format is common. Filename extensions of .cnf, .conf, .cfg, .cf or .ini are often used.

Almost all formats allow comments, in which case, individual settings can be disabled by prepending with the comment character. Often the default configuration files contain extensive internal documentation in the form of comments[1][2] and man 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 a period, which in 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". See run commands for further details.

By contrast, IBM's AIX uses an Object Data Manager (ODM) database to store much of its system settings.

MS-DOS[edit]

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 text batch file named AUTOEXEC.BAT that ran a series of commands on boot. Both these files were retained up to Windows 98SE, which still ran on top of MS-DOS.

An example CONFIG.SYS for MS-DOS 5:

DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE RAM
DEVICEHIGH=C:\DOS\ANSI.SYS
FILES=30
SHELL=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]

Microsoft Windows[edit]

The REGEDIT application being used to edit Windows Registry data

The early Microsoft Windows family of operating systems heavily utilized plain-text INI files (from "initialization"). These served as the primary mechanism to configure the operating system and application features.[4] The APIs 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 the Windows Registry, a hierarchical database to store configuration settings, which was introduced that year with Windows NT.

macOS[edit]

The Property List is the standard configuration file format in macOS (as well as in iOS, NeXTSTEP, GNUstep and Cocoa applications). It uses the filename extension .plist.

IBM OS/2[edit]

IBM's OS/2 uses a binary format, also with a .INI suffix, but this differs from the Windows versions. It contains a list 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 and OpenHarmony operating systems[edit]

HarmonyOS and OpenHarmony-based operating systems uses “config.json” configuration file in the root directory of each HAP application. It contains three modules such as app, deviceConfig and Module. The config.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 of JSON. HarmonyOS’ DevEco Studio provides two methods for editing config.json: the code editing view and the visual editing view. The `app` object holds the universal configuration details for the application, as demonstrated in the config.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. The Module 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. The MainAbility Indicates the name of HAP package’s entrance ability.[6]

Serialization formats[edit]

A number of general-purpose serialization 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 in open-source and platform-neutral software applications and libraries. The specifications describing these formats are routinely made available to the public, thus increasing the availability of parsers and emitters across programming languages.

Examples include: JSON, XML, and YAML.

Comparison[edit]

Format comparison[7]
Format Formal specs Allows comments Syntax typing[8][9]
CUE[10] Yes Yes Yes
INI No Yes No
JSON Yes[11] No Yes
TOML Yes[12] Yes Yes
YAML Yes[13] Yes Yes
XML Yes[14] Yes No

See also[edit]

  • .properties, a file extension mainly used in Java
  • HOCON, a superset of .properties and JSON
  • INI file, a common configuration file format
  • JSON, with support for complex data types and data structures
  • Run commands, which explains the historical origin of the "rc" suffix
  • TOML, a formally-specified configuration file format
  • YAML, with support for complex data types and structures

References[edit]

  1. ^ https://opensource.apple.com/source/postfix/postfix-174.2/Postfix.Config/main.cf.default. Archived 2017-08-03 at the Wayback Machine
  2. ^ http://opensource.apple.com/source/apache/apache-769/httpd.conf. Archived 2020-08-01 at the Wayback Machine
  3. ^ "rc file". Catb.org. Retrieved 2012-02-29.
  4. ^ Microsoft: Windows NT Workstation Resource Kit.
  5. ^ The OS/2 INI Files by James J. Weinkam.
  6. ^ Evans, Melissa. "HarmonyOS (Hongmeng) — config.json". Mo4Tech. Mo4Tech. Retrieved 24 March 2024.
  7. ^ TOML, TOML, 2023-01-15, retrieved 2023-01-15
  8. ^ Syntax typing refers to the use of syntax to designate data types. In languages that allow syntax typing, type declaration will be syntax-based – e.g. true will be a boolean while "true" will be a string – whereas in languages that do not allow syntax typing it will be semantics-based – e.g. true and "true" will be both recognizable as booleans, while microwave 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).
  9. ^ Opinions on whether syntax typing in configuration formats is a good or a bad feature vary among authors. with some considering it a disadvantage (see for example What is wrong with TOML § Syntax typing) and others favoring it.
  10. ^ "About | CUE". Retrieved October 6, 2022.
  11. ^ "The JavaScript Object Notation (JSON) Data Interchange Format".
  12. ^ "TOML Specification".
  13. ^ "YAML™ Specification Index".
  14. ^ "Extensible Markup Language (XML) 1.0 (Fifth Edition)".