Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know many directories with .d in their name:


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", I hope this is clearer now.

share|improve this question
I'm also interested in the origin of the naming convention. – phunehehe Nov 13 '10 at 17:35
For the origin of .d, see msw's comment on this related question at Ask Ubuntu. – Gilles Nov 13 '10 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 Nov 13 '10 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 Nov 13 '10 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. – LiuYan 刘研 Jul 21 '11 at 6:51
up vote 33 down vote accepted

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) an the directories they use (/etc/init.d, /etc/rc0.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.

share|improve this answer
+1, I think you're right, but no one so far has given any quote for his theory – greg0ire Nov 14 '10 at 12:04
It's more of a convention that kind of grew on people than an actual explicit standard, I think – Shadur Aug 10 '11 at 4:35
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 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.

share|improve this answer
Surprising... I would have thought this spoke in favour of the "directory", meaning "this is the directory part of the configuration". – greg0ire Nov 13 '10 at 22:50
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. – underscore_d Oct 29 '15 at 22:22

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.

share|improve this answer
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 Jul 21 '11 at 8:45
^ 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. – underscore_d Oct 29 '15 at 22:28

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.

share|improve this answer
Not really, these are directory names. – Keith Jul 21 '11 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 Jul 21 '11 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 Jul 21 '11 at 6:25
@Tim Post: see the above 2 comments (and Keith's answer), I'l soon edit my answer. – Philomath Jul 21 '11 at 6:28
Edited (15 chr) – Philomath Jul 21 '11 at 7:53

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.

share|improve this answer
+1, this explains a lot, but... not the choice of the 'd' letter. – greg0ire Nov 13 '10 at 17:52
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 Nov 13 '10 at 18:18

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.

share|improve this answer
+1, but... same remark as above. – greg0ire Nov 13 '10 at 17:53
@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. – Chris Johnsen Nov 14 '10 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 Nov 14 '10 at 11:17

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.

share|improve this answer
+1 for the delirium at the end, but I think this does not fit well with yum.repos.d ... – greg0ire Nov 13 '10 at 22:47
</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
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 Nov 15 '10 at 19:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.