Apparently contradicting login vs. non-login shell upon ssh

Question

I am running RHEL6 (kernel 2.6.32-573.el6.x86_64). I have aliases which are sourced upon sshing into myserver. One of these is

alias scl-devtoolset-3='source /usr/local/bin/scls/devtoolset-3'

It is presumably aliased in non-login shells (see below), but sshing gives a login shell, and this is confirmed by the line

shopt -q login_shell && echo 'This is a login shell' || echo 'This is a non-login shell'

in my ~/.bashrc, which produces

This is a login shell

as expected. Thus, I have no idea why/where is the alias set.

How to rationalize this seemingly contradictory circumstance?

---

Files present in my system:

/etc/profile
/etc/bashrc
/etc/profile.d/*
~/.bashrc

Files not present in my system:

/etc/bash.bashrc
~/.profile

---

TL;DR

The alias appears to be set (only in non-login shells) by the following lines in /etc/bashrc:

...
if ! shopt -q login_shell ; then # We're not a login shell
    ...
    # Only display echos from profile.d scripts if we are no login shell
    # and interactive - otherwise just process them to set envvars
    for i in /etc/profile.d/*.sh; do
        if [ -r "$i" ]; then
            if [ "$PS1" ]; then
                . "$i"
            else
                . "$i" >/dev/null 2>&1
            fi
        fi
    done
...
fi

which source file /etc/profile.d/scl-aliases.sh containing

#!/bin/bash

sources_dir=/usr/local/bin/scls

for scl in `ls $sources_dir`; do
        alias scl-$scl="source $sources_dir/$scl"
done

and given that

$ ls /usr/local/bin/scls
devtoolset-3  devtoolset-4  devtoolset-6  python27  python33

This was (partially?) confirmed by executing bash -x at the command prompt after sshing.

Answer 1

This is actually normal behavior. It comes down to the different files sourced by login vs non-login scripts. This has been covered extensively elsewhere but, briefly, (interactive) non-login bash shells source the bashrc family of files (/etc/bash.bashrc, ~/.bashrc) and (interactive) login shells source the various profile files (/etc/profile, ~/.profile).

So, your /etc/bashrc (which I think is the equivalent of /etc/bash.bashrc on macOS and maybe other systems) is only read by interactive non-login shells and remote shell daemons. When that file is read, if the shell reading it is a non-login shell (so not a remote shell daemon), it also brings in specific files under /etc/profile.d.

Login shells, however, don't read this file so it isn't relevant here. Instead, they will read /etc/profile and if you check that file, you will find something like this (from the /etc/profile file on my Arch):

# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
    for profile in /etc/profile.d/*.sh; do
        test -r "$profile" && . "$profile"
    done
    unset profile
fi

So that's why you're seeing these in a login shell. It's because login shells don't work through bashrc and instead have their own setup files and those are bringing in the files under /etc/profile.d but without excluding login shells.

Answer 2

I am posting this as an answer, given that comments cannot have indented code. Kudos to the answer by terdon.

As stated by terdon, my /etc/profile has the following lines.

for i in /etc/profile.d/*.sh ; do
    if [ -r "$i" ]; then
        if [ "${-#*i}" != "$-" ]; then
            . "$i"
        else
            . "$i" >/dev/null 2>&1
        fi
    fi
done

These would be responsible for the alias, not /etc/bashrc. This could be easily verified with a solution for Trace sequence of scripts/commands executed upon ssh