Take the 2-minute tour ×
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.

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 ?

share|improve this question

2 Answers 2

up vote 11 down vote accepted

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

share|improve this answer
    
Does it have positive ... and understood. What are you trying to say here ? I understood everything other than that paragraph. –  AsheeshR Feb 9 '13 at 14:22
    
The shell environment is generally used for configuring the shell itself and other ubiquitous tools. This is not the only way that configuration could be done, so it is worth considering whether the environment is better or worse than the other options. By having "positive value", I meant that using the environment does seem to have some advantages over other options at least WRT "managing simple parameters" -- namely that it is very efficient and "widely recognized and understood"...and I'll add a bit to explain that phrase further. –  goldilocks Feb 9 '13 at 16:23
    
What about appending lines to profile.local? Is this acceptable vs. creating scripts in the profile.d folder? –  Avindra Goolcharan Jul 30 at 18:32
    
@AvindraGoolcharan Different distros may use different schemes for this kind of thing. The profile.d directory only works because its contents are sourced by /etc/profile, which is specified by shells such as bash as a startup file (see INVOCATION in man bash); if you edit /etc/profile, you can disable /etc/profile.d. /etc/profile.local seems to be a SUSE invention, presumably sourced from somewhere such as /etc/profile so that you can put your own stuff there. However, if you move it to a non SUSE system and don't make any other adjustments, it won't be used by anything. –  goldilocks Jul 30 at 19:09
    
Gotcha, that's crystal clear. Yeah we use SUSE at my job. /etc/profile. seems like a much better bet. –  Avindra Goolcharan Jul 31 at 22:49

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.

share|improve this answer
    
The second paragraph is interesting. Since different shells support different syntax, this would require that there be a significant common syntax. True for bash and sh, but I don't think so for others like csh or tcsh, which have their own global login startup scripts. On many systems, /bin/sh is just a link to /bin/bash. But bash modifies its behavior to be posix-compliant when invoked as sh. So one would think that authors of scripts in /etc/profile.d would need to be careful to avoid using bash extensions outside the posix subset. –  sootsnoot Oct 10 at 6:28

Your Answer

 
discard

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.