170

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".

7
  • 14
    For the origin of .d, see msw's comment on this related question at Ask Ubuntu. Commented Nov 13, 2010 at 18:09
  • @Gilles, ha, I was thinking it was later than System-V, but yeah, even still there is no meaning to '.d' it was just chosen from what I can tell.
    – N J
    Commented Nov 13, 2010 at 18:24
  • @Gilles : interesting, the answer seems to be : the explanation was lost... as per the first comment of the first answer in your link
    – greg0ire
    Commented Nov 13, 2010 at 18:39
  • Not sure why .d in init.d, but it seems almost all custom config files go to .d directories in RHEL/CentOS/Fedora. Commented Jul 21, 2011 at 6:51
  • @Liu Yan - Indeed, I could not explain it in any manner that could be construed as consistent.
    – Tim Post
    Commented Jul 21, 2011 at 7:06

7 Answers 7

153

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.

3
  • It's more of a convention that kind of grew on people than an actual explicit standard, I think Commented Aug 10, 2011 at 4:35
  • 1
    When you do an 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
    Commented Dec 25, 2012 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. Commented Oct 29, 2015 at 22:20
73

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.

2
  • 9
    Surprising... I would have thought this spoke in favour of the "directory", meaning "this is the directory part of the configuration".
    – greg0ire
    Commented Nov 13, 2010 at 22:50
  • 2
    It clearly does. Why someone would read this and conclude that the .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. Commented Oct 29, 2015 at 22:22
17

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.

5
  • Not really, these are directory names.
    – Keith
    Commented Jul 21, 2011 at 6:04
  • @Keith: oops, I mistakenly thought he speaks about files ending with "d", like syslogd, not directories ending with ".d". I'l edit soon.
    – Philomath
    Commented Jul 21, 2011 at 6:14
  • That's what I thought, but I see it used often in configuration directories for programs that don't daemonize, e.g. sysctl.d, modprobe.d .. would that be an inappropriate use?
    – Tim Post
    Commented Jul 21, 2011 at 6:25
  • @Tim Post: see the above 2 comments (and Keith's answer), I'l soon edit my answer.
    – Philomath
    Commented Jul 21, 2011 at 6:28
  • Edited (15 chr)
    – Philomath
    Commented Jul 21, 2011 at 7:53
4

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.

2
  • 1
    Does there have to be an explanation for the choice? It is just a convention that has developed over time, it's not (from a quick look) defined in the FHS, but it may be included in the LSB standard. Cron was one of the first as I recall. (Edit: in fact it would have been init)
    – N J
    Commented Nov 13, 2010 at 18:18
  • An explanation for the choice would, in fact, be nice. Why did they choose ".d", and not ".e" or ".f"? Were they trying to communicate something? Did they pick a letter out of a hat? If there was a good reason for the choice they made, that could be educational for those of us who are new to this convention. Commented Mar 28, 2023 at 12:43
3

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.

2
  • 1
    @greg: Due to the variety of ways to sort answers, “above” and “below” are poor ways to refer to (comments on) other answers. The ‘oldest’ and ‘newest’ sorts produce opposite meanings for such position-based descriptions, and when sorting by ‘votes’ the relative position of two answers may change over time. Commented Nov 14, 2010 at 5:44
  • @Chris Johnsen: this is what I realized, but too late. I was referring to my comment on N J's answer.
    – greg0ire
    Commented Nov 14, 2010 at 11:17
3

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.

2
  • 7
    In addition the .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
    Commented Jul 21, 2011 at 8:45
  • 3
    ^ I'd go so far as to say that's not an "addition" but the very reason for the convention in the first place. Unix/Linux has never been precious about having to include extensions on things, especially in the early days, so I doubt this one was bandied around without a good reason. Commented Oct 29, 2015 at 22:28
1

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.

3
  • </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. Commented Nov 14, 2010 at 23:22
  • 1
    The question is "what does the '.d' stand for", and I have received plenty of explanations concerning the reason why there is this '.d', but the few that gave an answer regarding the meaning did not quote any source. Personnaly, I think it means directory.
    – greg0ire
    Commented Nov 15, 2010 at 19:41
  • 1
    yum is a more recent invention. Commented Sep 22, 2016 at 21:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .