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.

In addition there is another post from OP here https://unix.stackexchange.com/questions/408095/trace-sequence-of-scripts-commands-executed-upon-ssh ...it is directly related to this one...it should not be separate IMO — B Layer, Dec 01 '17 at 04:07
@BLayer I don't see why the two are related. Yes, the second might be a useful tool for this one, but it is a separate question and can (and should) stand on its own. — terdon, Dec 01 '17 at 14:42
@terdon Surely you see how they are related. OP posted that question while working on the problem then less than an hour later posted this question (presumably after getting more information by using `-x`). Given the cross-posting I don't think OP is shy about creating new posts thus I think the intent was not to post two distinct questions. Oh, and the first one is like two sentences long. Anyways, I'm just making a suggestion to help keep things uncluttered around here (a losing battle, I know). — B Layer, Dec 02 '17 at 09:39
OP here... Just a few comments. 1) Yes, this is cross-posted. I am not sure this is "bad practice", given that the two sites seem to be a perfect fit for the question, and that is why I cross-posted. I wouldn't see strong arguments against it. And if so, they would perhaps also touch upon the existence of the two sites. 2) I am not "shy" about creating new posts, whenever I think them useful for the community and myself. I usually do reasonable to significant research prior to posting, probably well above average (without being infallible)... TBC — sancho.s ReinstateMonicaCellio, Dec 04 '17 at 03:42
... Cont. 3) The two questions came from a single work session, but I still consider them two different questions, with their own separate meaning, coinciding 100% with @terdon. — sancho.s ReinstateMonicaCellio, Dec 04 '17 at 03:45
4) The first one is not "like" two sentences long... it is two sentences long. Would this make it less worth @BLayer? In the end, I see little focus on the question itself... — sancho.s ReinstateMonicaCellio, Dec 04 '17 at 03:47
This is a huge discussion that has been had many times over on the main meta and ours, let's not repeat it in the comments. By the way, have you answered your question? If so, please post it as an answer. If not, I think the missing piece you're looking for is explained in [this excellent answer](https://unix.stackexchange.com/a/257613/22222). — terdon, Dec 04 '17 at 14:14
@terdon - I agree in that the answer you linked is quite comprehensive. But I did not find it answers this question. It would not explain why the test `shopt -q login_shell` gives True when evaluated in ~/.bashrc, and it gives False when evaluated in `/etc/bashrc`, both in the same shell. That is assuming the alias is set within the cited `if` construct (otherwise, I wouldn't know where is it set). If you can reinterpret the answer in a way to answer this OP, please post the answer... I would very much welcome it! — sancho.s ReinstateMonicaCellio, Dec 04 '17 at 18:23
Ah, I only now understood what is confusing you. Could you edit and clarify a bit? I mean state explicitly that your question is why is this alias set in login shells. Also, what OS is this? Is it Ubuntu (since you'd posted there)? And do you really mean `/etc/bashrc` or is it `/etc/bash.bashrc`? If the former, would you be running macOS by any chance? — terdon, Dec 04 '17 at 20:33

score 1 · Answer 1 · answered Dec 04 '17 at 20:49

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.

score 0 · Answer 2 · answered Dec 05 '17 at 00:33

0

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

answered Dec 05 '17 at 00:33

sancho.s ReinstateMonicaCellio

2,630
1
16
31

I don't understand. Why are you posting this? Isn't this exactly what I explained in my answer? What am I missing? – terdon Dec 05 '17 at 00:40
@terdon - The precise lines are not the same, even if functionally equivalent. I thought that was worth posting (as a comment), for any one who might not recognize the alternative syntax to see it explicitly. I would value it as a reader. – sancho.s ReinstateMonicaCellio Dec 05 '17 at 01:21

Apparently contradicting login vs. non-login shell upon ssh

2 Answers2

Linked