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:
- Because that would be a maintenance nightmare for the people who are responsible for the scripts.
- 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.
- 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?" That begs another question, "Why would startup not be?", to which one obvious objection might be, "Well because that is not very efficient -- all that data which may or may not get used..." 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.
