What do the scripts in /etc/profile.d do?

Question

I am reading about basic shell scripting from Linux Command Line and Shell Scripting Bible.

It says that the /etc/profile file sets the environment variables at startup of the Bash shell. The /etc/profile.d directory contains other scripts that contain application-specific startup files, which are also executed at startup time by the shell.

• Why are these files not a part of /etc/profile if they are also critical to Bash startup ?

• If these files are application-specific startup files not critical to Bash startup, then why are they part of the startup process ? Why are they not run only when the specific applications, for which they contain settings, are executed ?

Answer 1

Why are these files not a part of /etc/profile if they are also critical to Bash startup ?

If you mean, "Why are they not just combined into one giant script?", the answer is:

1. Because that would be a maintenance nightmare for the people who are responsible for the scripts.
2. Because having the scripts loaded as independent modules makes the whole system more dynamically adjustable -- individual scripts can be added and removed without affecting the others. Etc.
3. Because they are loaded via /etc/profile which makes them a part of the bash "profile" in the same way anyway.

If these files are application-specific startup files not critical to Bash startup, then why are they part of the startup process ? Why are they not run only when the specific applications, for which they contain settings, are executed ?

That seems to me like a broader design philosophy question that I'll split into two. The first question is about the value and appropriateness of using the shell environment. Does it have positive value? Yes, it is useful. Is it the best solution to all configuration issues? No, but it is very efficient for managing simple parameters, and also widely recognized and understood. Contrast that to say, deciding to configure such things heterogeneously, perhaps $PATH could be managed by a separate independent tool, preferred tools such as $EDITOR could be in an sqlite file somewhere, $LC lang stuff could be in a text file with a custom format somewhere else, etc -- doesn't just using env variables and /etc/profile.d suddenly seem simpler? You probably already know what an env variable is, how they work and how to use them, vs. learning 5 completely different mechanisms for 5 different ubiquitous aspects of what is appropriately named "the environment".

The second question is, "Is startup the appropriate time for this?", which begs the objection that it is not very efficient (all that data which may or may not get used, etc). But:

• Realistically, it is not all that much data, partially because no one in their right mind would use it for more than a few simple parameters (since there are other means of configuring an application).
• If it is used wisely, with regard to things that are commonly invoked, then setting, eg, default $CFLAGS from a file somewhere every time you invoke gcc would be less efficient. Keep in mind that the amount of memory involved is, again, infinitesimal.
• It can involve systemic things which more than one application may be involved with, and the shell is a common ground.

More could be added to that list, but hopefully this gives you some idea about the pros and cons of the issue -- the major 'pro' and the major 'con' being that it is a global namespace.

Answer 2

Those files are specific to an application, but are sourced at shell startup, not when the application starts. A configuration directory is used here for the same reason that it is found in many other places. This allows an application or software package to modify configurations. This wouldn't be possible without a split configuration, as multiple packages trying to manage/update a single configuration file that can also be modified by the user would be buggy and messy.

Also a side note, /etc/profile is sourced by all shells, not just bash. The bash specific configuration file is bashrc and only sourced for interactive shells.

Answer 3

jordanm's answer is incorrect. /etc/profile is not sourced by all shells. As you point out, it is not sourced by csh, tcsh - I'm not sure about zsh. It is sourced by Bourne shell (sh) derivatives, like Korn Shell (ksh) and BASH (bash). csh uses /etc/login. People who tend to exclusively use Borne Shell derivatives tend to forget other shells exist. They add something to /etc/profile expecting it to apply to "all users" and then are surprised when the odd C Shell user (and we are an odd lot) doesn't have the stuff they configured in /etc/profile.

Even so, people tend to forget about other Borne Shell derivative shells exist. If they use bash or ksh, they feel free to add syntax to /etc/profile that is not valid in Bourne Shell, like say defining a variable and exporting it on the same line. Then you get some script that does #!/bin/sh and it chokes on the syntax. /etc/profile should stick to Bourne Shell compatible syntax.

Likewise, you should stick to it in your own .profile (use .bash_profile if you want some bash syntax) - it may be a little extra typing, but it is extra typing you do all of once. Reference ${HOME} and not ~, etc. Some flavors of Unix, cron jobs run under sh, each line of your Makefile is processed by sh, so if you're working across multiple flavors of UNIX, it really pays to keep your .profile Bourne shell compatible. As a SysAdmin, I can't tell you how many times I've helped someone by fixing up their .profile to be Bourne Shell compatible.

On Linux, /bin/sh is a link to /bin/bash and when you run it, it looks a the path that was used to run it, and (in theory) limits itself to only things that Bourne Shell supports. Likewise, vi on Linux is really vim, again limiting itself. Occasionally you see features "bleed through". Occasionally vim pretending to be vi will do something that vim supports that vi does not because the authors of vim forgot to disable this in "vi backwards compatibility" mode. I would not be surprised if bash pretending to be sh has some similar "bleed through" features. Wouldn't be surprised if some feature "works on Borne Shell on Linux", but not on a System V or BSD based UNIX (AIX, OpenBSD, etc.).