Bash startup files

[GianPiero Puccioni]

Hi,

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 sources
/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?

GianPiero

[Cameron Simpson]

On 25Oct2017 14:24, GianPiero Puccioni <gianpiero.puccioni(a)isc.cnr.it&gt; wrote:
> 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 sources
> /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.

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, etc).

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.

In the modern world (GUI desktop) the picture is complicated and what you're 
observing is probably a consequence of bad decisions to address that 
complication.

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 sourcing 
/etc/profile stuff.

Hoping this explains the situation somewhat.

Cheers,
Cameron Simpson <cs(a)cskk.id.au&gt; (formerly cs(a)zip.com.au)

[George N. White III]

On 25 October 2017 at 19:13, Cameron Simpson <cs(a)cskk.id.au&gt; wrote:

>  On 25Oct2017 14:24, GianPiero Puccioni
> <gianpiero.puccioni(a)isc.cnr.it&gt;
>  wrote:
>
> > 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
> > sources
> > /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,
>  etc).
>
>  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:
https://www.redhat.com/archives/nahant-list/2007-May/msg00235.html


>  In the modern world (GUI desktop) the picture is complicated and
> what
>  you're observing is probably a consequence of bad decisions to address that
>  complication.
>
>  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
> sourcing
>  /etc/profile stuff.
>
>  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
pointy-clicky types

2.  pointy-clicky types find fewer frustrations and may decide that linux
can be useful

-- 
George N. White III <aa056(a)chebucto.ns.ca&gt;
Head of St. Margarets Bay, Nova Scotia

[Tim]

Allegedly, on or about 26 October 2017, George N. White III sent:
>  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 pointy-clicky types
>  
>  2.  pointy-clicky types find fewer frustrations and may decide that
>  linux can be useful 
While that may be so, it is advantageous if they continue to do things,
behind the scenes, in the traditional way.

 * Less re-inventing of the wheel.
 * Less surprises when someone customises something following
   established instructions.
 * Settings for things stored in the same place, whether you work from
   the command line or a GUI...

Having said that, the whole BASH config file conglomeration does not
look pretty to me.

Let's say that I want to make an alias that all users can use.  I'm not
sure where it goes, bashrc or profile.

   less /etc/bashrc 
   # /etc/bashrc
   # System wide functions and aliases
   # Environment stuff goes in /etc/profile

Okay, having read that, I'll go look at /etc/profile.  It seems to
suggest that aliases go in /etc/profile.

   less /etc/profile
   
   # /etc/profile
   # System wide environment and startup programs, for login setup
   # Functions and aliases go in /etc/bashrc

It seems to suggest that aliases go in /etc/bashrc.

There's some shockingly bad grammar in those opening descriptions.  I
can't really tell if the bashrc description is meant to say this file
is for system wide functions and aliases, profile is for environment
stuff.  It looks like one long badly typed sentence.  Programmers
should write coherent sentences, and it'd help if they used normal
punctuation.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 4.13.5-200.fc26.x86_64 #1 SMP Thu Oct 5 16:53:13 UTC 2017 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.

- And how would you describe Windows?
- One man's trash is another man's treasure...

[Tom H]

On Wed, Oct 25, 2017 at 6:13 PM, Cameron Simpson <cs(a)cskk.id.au&gt; wrote:
>  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.
>
>  Second, /etc/bashrc should _not_ be sourcing anything in
>  /etc/profile.d. That is for _login_ shells. 
Fedora's been sourcing "/etc/profile.d/*.sh" for many years. IIRC, the
rationale's that it equalizes login and interactive sessions.

[Cameron Simpson]

On 28Oct2017 10:02, Tom H <tomh0665(a)gmail.com&gt; wrote:
> On Wed, Oct 25, 2017 at 6:13 PM, Cameron Simpson <cs(a)cskk.id.au&gt;
> wrote:
> >
> > 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.
> >
> > Second, /etc/bashrc should _not_ be sourcing anything in
> > /etc/profile.d. That is for _login_ shells.
>
> Fedora's been sourcing "/etc/profile.d/*.sh" for many years. IIRC, the
> rationale's that it equalizes login and interactive sessions. 
[ Specificly, ourcing this from the bashrc. ] Yeah I know. I loathe it. I 
understand the tradeoff there, and why it came about. Still unhappy.

Cheers,
Cameron Simpson <cs(a)cskk.id.au&gt; (formerly cs(a)zip.com.au)

[George N. White III]

On 25 October 2017 at 09:24, GianPiero Puccioni <
gianpiero.puccioni(a)isc.cnr.it&gt; wrote:

>  Hi,
>
>  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 sources
>  /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?
>  
On fedora 26 server, /etc/skel/.bashrc is:


# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# Uncomment the following line if you don't like systemctl's auto-paging
feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions

I take the last line as a hint that users should add stuff to the end of
the file. If I put alias ls="ls -lh" after the last line, it is respected
in new shells.

-- 
George N. White III <aa056(a)chebucto.ns.ca&gt;
Head of St. Margarets Bay, Nova Scotia

[Cameron Simpson]

On 26Oct2017 12:57, George N. White III <gnwiii(a)gmail.com&gt; wrote:
> On fedora 26 server, /etc/skel/.bashrc is:
>
> # .bashrc
>
> # Source global definitions
> if [ -f /etc/bashrc ]; then
>     . /etc/bashrc
> fi
>
> # Uncomment the following line if you don't like systemctl's auto-paging
> feature:
> # export SYSTEMD_PAGER=
>
> # User specific aliases and functions
>
> I take the last line as a hint that users should add stuff to the end of
> the file. If I put alias ls="ls -lh" after the last line, it is respected
> in new shells. 
The hint could be better. While it might seem obvious, saying the "User 
specific aliases and functions should go below this line" might be an 
improvement.

I'm presuming the OP put their stuff up the top.

Cheers,
Cameron Simpson <cs(a)cskk.id.au&gt; (formerly cs(a)zip.com.au)

[GianPiero Puccioni]

[Cameron Simpson]
>  The hint could be better. While it might seem obvious, saying the
> "User
>  specific aliases and functions should go below this line" might be an
>  improvement.
>
>  I'm presuming the OP put their stuff up the top. 
Yes I did, but I realized that my .bashrc comes from a very old Fedora, as I 
reinstalled several versions on this machine, and that was the suggestion at 
time (I think).

My point was more about the fact that profile.d was sourced by both /etc/bashrc 
and /etc/profile and this didn't sound right.

GianPiero