Re: What does .d at the end of some dirctory and filenames actually stand for?
"email@example.com" <firstname.lastname@example.org> writes:
> I (and some other people) are wondering about the question:
> "What does .d at the end of some dirctory and filenames actually stand for?"
> It does not mean deamon or default.
> Does it maybe mean directory? Probably not, cause there are files named
> "x.d" too.
Once upon a time, most UNIX software was controlled by a single
configuration file per software package, and all the configuration details
for that package went into that file. This worked reasonably well when
that file was hand-crafted by the system administrator for local needs.
When distribution packaging became more and more common, it became clear
that we needed better ways of forming such configuration files out of
multiple fragments, often provided by multiple independent packages. Each
package that needs to configure some shared service should be able to
manage only its configuration without having to edit a shared
configuration file used by other packages.
The most common convention adopted was to permit including a directory
full of configuration files, where anything dropped into that directory
would become active and part of that configuration. As that convention
became more widespread, that directory was usually named after the
configuration file that it was replacing or augmenting. But since one
cannot have a directory and a file with the same name, some method was
required to distinguish, so .d was appended to the end of the
configuration file name. Hence, a configuration file /etc/Muttrc was
augmented by fragments in /etc/Muttrc.d, /etc/bash_completion was
augmented with /etc/bash_completion.d/*, and so forth. Sometimes slight
variations on that convention are used, such as /etc/xinetd.d to
supplement /etc/xinetd.conf, or /etc/apache2/conf.d to supplement
/etc/apache2/apache2.conf. But it's the same basic idea.
Generally when you see that *.d convention, it means "this is a directory
holding a bunch of configuration fragments which will be merged together
into configuration for some service."
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>