You are not logged in.
Not sure I understand the meaning of this yet, but in 2017 Arch enabled the NON_INTERACTIVE_LOGIN_SHELLS compile-time option:
https://gitlab.archlinux.org/archlinux/ … 56b5d087b8
I didn't find any explanation. There is no commit message, that option is not mentioned on the wiki, and the only mention I found on the mailing lists is from 2011 and doesn't seem related:
https://lists.archlinux.org/archives/li … ANT3LT5UO/
Upstream update. Big changelog below. I have been running the various
RCs (12 of them!) without issue for a while.Signoff both,
AllanWhat's new in Sudo 1.8.2?
<snip>
* "sudo -i command" now works correctly with the bash version
2.0 and higher. Previously, the .bash_profile would not be
sourced prior to running the command unless bash was built with
NON_INTERACTIVE_LOGIN_SHELLS defined.
The option was added to bash around the year 2000:
------------------------------------------------------------------------------
This document details the changes between this version, bash-2.04-alpha1,
and the previous version, bash-2.04-devel.1. Changes to Bash
<snip>
e. Restored the undocumented NON_INTERACTIVE_LOGIN_SHELLS #define to
config-top.h. If this is defined, all login shells will read the
startup files, not just interactive and non-interactive started with
the `--login' option.
Offline
Some relevant discussion on the bug-bash mailing list:
ssh changed from socket to pipe stdin, Roman Rakus, 2008/10/23
Re: ssh changed from socket to pipe stdin, Chet Ramey, 2008/10/23
and with this change .bashrc is never sourced. Will we do something with this? Changing check from socket to pipe stdin will cause problems with older ssh. Maybe defining SSH_SOURCE_BASHRC? Or just don't do anything?
RR
This is the reaason that SSH_SOURCE_BASHRC exists, but you have to accept the consequences of enabling it.
Changing the shell to check whether stdin is a pipe and sourcing the .bashrc in that case will cause havoc -- every invocation of bash -c by a program that uses a pipe for input and output to that shell will cause the .bashrc to be sourced. This seems like something that would cause more trauma than would be worth it.
The problem with SSH_SOURCE_BASHRC is that it looks for environment variables set by sshd that persist across shell invocations. This means that other programs running bash to execute non-interactive commands with `bash -c' will result in sourcing .bashrc, with unpredictable consequences. This isn't that great, either.
So far, neither solution has been clean enough for me to consider changing the current behavior. Ultimately, you'll have to decide what is best for your customers, but you should at least know what you'll potentially be in for.
Chet
First lines of examples/startup-files/bashrc, Martin Schulte, 2020/04/08
Re: First lines of examples/startup-files/bashrc, Chet Ramey, 2020/04/09
Hello bash developers,
my apologies in advance if I'm overlooking something trivial but I'm really wondering about the first lines in examples/startup-files/bashrc (which are copied to Debian's skeleton ~/.bashrc):
case $- in
*i*) ;;
*) return ;;
esacWell, bash terminates sourcing the file if it is invoked non-interactively.
But, as far as I understand, a non-interactive bash doesn't read ~/.bashrc at all - so shouldn't we just omit them?
Best regards,
Martin
My guess is that Debian has compiled bash with SSH_SOURCE_BASHRC defined.
So it sound like the interactivity guard in bashrc in Debian could be there to work around undesirable side effects of the SSH_SOURCE_BASHRC option. However as far as I could see Arch has never used the SSH_SOURCE_BASHRC. Note that the SSH special case mentioned in the bash manual and discussed earlier in this thread is based on detecting socket standard input and is always enabled, not a compile-time option. SSH_SOURCE_BASHRC additionally checks for the presence of environment variables SSH_CLIENT or SSH2_CLIENT.
Offline
I tried logging non-interactive login instances from /etc/profile and found nothing yet. Is anyone else curious enough to try it on their machine? I don't have a display manager which is one case I saw mentioned that might run non-interactive login shells.
This is what I put in /etc/profile:
case "$-" in *i*) ;; *)
echo user:$USER name:$0 option:$- | systemd-cat --identifier=profile
esacOffline
Explanation for NON_INTERACTIVE_LOGIN_SHELLS option being enabled in 2017:
Bug 736660 - wayland session does not process .bash_profile - Comment 110
FS#50567 - [bash] Define NON_INTERACTIVE_LOGIN_SHELLS
Also, original reasoning behind the NON_INTERACTIVE_LOGIN_SHELLS option:
bash doesn't run as a login when when -c specified, Todd . Miller, 2011/06/27
Re: bash doesn't run as a login when when -c specified, Chet Ramey, 2011/06/27
So bash at some point decided to ignore '-' preceding the name in the non-interactive case. Enabling NON_INTERACTIVE_LOGIN_SHELLS causes bash to have the same historical behavior as other shells: '-' in front of name is respected even in the non-interactive case so non-interactive login shells can be started using that mechanism.
Offline