I know many directories with .d in their name:
init.d
yum.repos.d
conf.d
Does it mean directory? If yes, from what does this disambiguate?
UPDATE: I've had many interesting answers about what the .d means, but the title of my question was not well chosen. I changed "mean" to "stand for".
The .d suffix here means directory. Of course, this would be unnecessary as Unix doesn't require a suffix to denote a file type but in that specific case, something was necessary to disambiguate the commands (/etc/init, /etc/rc0, /etc/rc1 and so on) and the directories they use (/etc/init.d, /etc/rc0.d, /etc/rc1.d, ...)
This convention was introduced at least with Unix System V but possibly earlier. The init command used to be located in /etc but is generally now in /sbin on modern System V OSes.
Note that this convention has been adopted by many applications moving from a single file configuration file to multiple configuration files located in a single directory, eg: /etc/sudoers.d
Here again, the goal is to avoid name clashing, not between the executable and the configuration file but between the former monolithic configuration file and the directory containing them.
ls command (not ls -al) without using the --color option (either explicitly specified or part of LS_OPTIONS environment variable), having the ".d" makes directories stand out from the list. That's why I always thought it was done.
– LawrenceC
Dec 25 '12 at 16:22
color is not the only, or best, way to visually flag directories. ls -F will do that and many more useful things.
– underscore_d
Oct 29 '15 at 22:20
Excerpt from a Debian mailing list (emphasis added):
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."
For part 2, the reason for the ".d", my best guess would be "distributed", as in not part of the main configuration file, but still part of the configuration.
.d meant anything else is beyond me! But this source only shows Debian's rationale for, in one context, using a convention that existed since the early days of Unix. I have to wonder whether this Debian maintainer was deliberately simplifying - or really thought Debian invented this practice.
– underscore_d
Oct 29 '15 at 22:22
If you speak about ".d" at the end of directory names, this answer is right, it's just a marker for "directory".
Just don't confuse it with "d" at the and of a file name, like "syslogd", which stands for daemon. A computer process running in the background.
the parent process of a daemon is often (but not always) the init process (PID=1). Processes usually become daemons by forking a child process and then having their parent process immediately exit, thus causing init to adopt the child process. This is a somewhat simplified view of the process as other operations are generally performed, such as dissociating the daemon process from any controlling tty. Convenience routines such as daemon(3) exist in some UNIX systems for that purpose.
syslogd, not directories ending with ".d". I'l edit soon.
– Philomath
Jul 21 '11 at 06:14
sysctl.d, modprobe.d .. would that be an inappropriate use?
– Tim Post
Jul 21 '11 at 06:25
It doesn't mean directory per se, basically what is happening is that directories that end in .d (note these are usually only ever in /etc), take configuration parts.
This is designed so distros can include universal defaults in for instance /etc/yum.conf, but then there is a easy to use method for users or other packages to append their own yum configurations in a safe way that won't be overwritten.
As an example for yum...
If I wanted to start using EPEL on my RHEL5 or CentOS Box, I can configure a new repository in the /etc/yum.repos.d folder, (say /etc/yum.repos.d/epel.repo) or install the epel-release package that creates the file automatically, without modifying my default configuration or causing file conflicts that don't need to happen.
What will happen, is most programs will read their default configuration (/etc/yum.conf for instance) and then iterate over their .d folders including configuration snippets into the running program.
Hope it explains it for you.
Just like files can have .ext to specify which type of file it is (commonly called the "extension"), directories sometimes have .d to show it's a directory and not a file. That's its type. The default ls output doesn't visually differentiate directories and files, so the .d is just an old convention to show its type (directory) in such listings.
.d suffix prevents collisions with a similarly-named file. For example, you can have a configuration file /etc/apt/sources.list, and a directory of configuration files /etc/apt/sources.list.d.
– jmtd
Jul 21 '11 at 08:45
More generally, the .d directories (/etc/httpd/conf.d, /etc/rc.d, /etc/being another example), indicates that the files contained will be read and used, often for configuration, if they match a given pattern and do not require being explicitly added to some master list.
So if you add files of the form *.repo to /etc/yum.repos.d, yum will use it when running without needing to add it to a list of configurations /etc/yum.conf. If you add files of the form *.conf to /etc/http/conf.d, they will be read by Apache without needing to be explicitly added to /etc/httpd/conf/httpd.conf. Similarly, chkconfig to files in /etc/init.d, cron jobs in /etc/cron.d.
I think, but cannot document, that the .d indicates that the directory is associated with a daemon.
Evidence would indicate that this is at least plausible:
sudo find / -maxdepth 3 -name "*.d"
Somewhere in the deep recesses of the little bits of ancient Unix history still rattling around in the back of my mind behind the cobwebs, this calls out to me as the correct answer. I believe it may have come from a time when the first mammals roamed the earth before the dinosaurs began to die out and man pages were not only kept on the system but also physically in racks measured by the foot.
</cobwebs> I believe the answers that indicate that the purpose of the .d is to disambiguate the directory from the related and similarly named files are the correct ones. I have upvoted E-man's and jlliagre's.
– Dennis Williamson
Nov 14 '10 at 23:22
.d, see msw's comment on this related question at Ask Ubuntu. – Gilles 'SO- stop being evil' Nov 13 '10 at 18:09.dininit.d, but it seems almost all custom config files go to.ddirectories in RHEL/CentOS/Fedora. – LiuYan 刘研 Jul 21 '11 at 06:51.emacs.dmade me post a duplicate. – Nikana Reklawyks Oct 29 '12 at 06:46