What does "rc" and ".d" stand for in file-/directory names?

Photo by Tima Miroshnichenko: https://www.pexels.com/photo/close-up-view-of-system-hacking-in-a-monitor-5380664/

This was a question which came up recently and while I could have given the answer based on my experience where these two strings commonly occur, I never really researched the initial origin.

Turns out rc has quite a heritage. Quoting from the Indiana Universities Knowledge Base:

runcom (as in .cshrc or /etc/rc)

The rc command derives from the runcom facility from the MIT CTSS system, ca. 1965. From Brian Kernighan and Dennis Ritchie, as told to Vicki Brown:

"There was a facility that would execute a bunch of commands stored in a file; it was called runcom for "run commands", and the file began to be called "a runcom". rc in Unix is a fossil from that usage."

Note: The name of the shell from the Plan 9 operating system is also rc.

And then I learned about the Plan 9 OS of which I've never heard before: https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

For .d there is not a real distinctive answer. It seems the common consensus is that it originated from /etc/rc?.d as to have a directory for runcoms and to distinguish it from a normal daemon configuration file - as these are typically stored under /etc. And/or to prevent naming-problems, as files & folders can't share the same name under Unix/Linux the .d as indicator for a directory was added.

And from there this mechanism was used for other daemons as well. What seems to have started as /etc/rc1.d, /etc/rc2.d, etc. as a way to separate runcoms to be executed on different runlevels, became commonly used today for the configuration of daemons/services.

Today a something.d directory holds configurations files for the something daemon. The advantage is that you are able to split your configuration in different files. Making it, for example, easier to deploy only certain files to certain hosts via your configuration management tool of choice (Puppet, Ansible, Chef, etc.). Additionally it's easier to spot configuration errors in a relatively small than in one big "contains it all"-file.