On 25 October 2017 at 19:13, Cameron Simpson <cs(a)cskk.id.au> wrote:
On 25Oct2017 14:24, GianPiero Puccioni
> I have a question about the system startup files for bash.
> The problem I had was that I set up an alias in ~/.bashrc, let's say
> alias ls="ls -lh"
> but it didn't work as "alias ls" reported
> alias ls='ls --color=auto'
> What happens is that at the end ~/.bashrc sources /etc/bashrc which
> /etc/profile.d/*.sh that redefine "ll".
> This happens on F24, F25, F26 and CentOS....
> Easy to correct, but the question is: is that right? None of the examples
> I found on line does that and /etc/profile.d/*.sh are already sourced by
> /etc/profile (which is the first startup file read on login). Is this a
> quirk of RedHat or an error that still remains in the files or what?
There are at least 2 things wrong.
First, the .bashrc (which one presumes first came from the template in
/etc/skel) should source /etc/bashrc _first_, not last.
The order in which things are done in ~/.bashrc is the responsibility of
the person who makes changes to the default. Maybe /etc/skel/.bashrc
should start with a paragraph explaining that user additions should be put
below the "User specific" line.
Second, /etc/bashrc should _not_ be sourcing anything in /etc/profile.d.
That is for _login_ shells.
Have a look at the "INVOCATION" section of "man bash".
Bash has roughly 3 modes: batch mode, interactive mode and login mode.
Batch mode is used to run scripts. It should basicly source nothing new.
An interactive shell should source your .bashrc, to get settings useful
for interactive use (convenience aliases like your "ls", prompt settings,
A login shell should source /etc/profile, to get per login fuller settings
(set up your $PATH, and so forth, often more expensive than plain
"interactive" shells). It is very common for this in turn to source your
.bashrc as a final act if the shell is also interactive.
So the bashrc has _no_ business sourcing /etc/profile or /etc/profile.d.
Ten years ago there was a discussion of whether this sourcing should be
done only for non-login shells, so it is not a new thing, see:
In the modern world (GUI desktop) the picture is complicated and
you're observing is probably a consequence of bad decisions to address that
In ancient times, one logged in on a serial terminal, or less anciently,
on a text mode PC console. You started a single login shell, which ran
/etc/profile once, setting up your environment. All subshells would be
interactive, sourcing the .bashrc (or equivalent) for interactive settings
like convenience aliases. You might then start X11 to get a GUI desktop,
and reasonably all the terminal emulators you then run would just run plain
interactive shells, since your /etc/profile had already happened.
With a GUI login, the desktop starts up and the terminals you might invoke
don't have the benefit of an original sourcing of /etc/profile (unless
you've made personal efforts to that end, as I do).
As a consequence, GUI desktop often start terminals with shells in "login"
mode inside them, expressly to ensure that you get your /etc/profile and
.profile sourced. Slower but gets it done. On a modern machine the
performance issue is usually minor.
However, terminal emulators might not do that. So someone in bash install
setup land for the various distros has taken it upon themselves to make
ordinary interactive shells act like login shells. Gah! Overkill.
However, that is the kind of decision that leads to the bashrc
Hoping this explains the situation somewhat.
When there is a choice between having more things "just work" for
pointy-clicky users who have never encountered a terminal at a cost of
additional complexity for guru-class users who work with the shell, the
"just work" option has advantages:
1. gurus spend less time sorting out problems with broken GUI apps for the
2. pointy-clicky types find fewer frustrations and may decide that linux
can be useful
George N. White III <aa056(a)chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia