Over the last few months I’ve been using 4 different computers running Manjaro-Plasma, and in regards to running a BASH shell in a terminal emulator (such as Konsole), 3 of them behave as you would expect: since such shells are “non-login interactive”, the files “/etc/bash.bashrc” and “~/.bashrc” are sourced, in that order.
Not so on the fourth computer! My Asus notebook which I call “Avalon”, which runs Manjaro-Plasma, has a totally different behavior! On launching Konsole (or any other terminal emulator), it launches a non-login interactive BASH shell (as normal), but it appears to have already sourced “/etc/profile” (apparently once-only, at startup), and it does not source “/etc/profile” again at shell launch, and it does not source “/etc/bash.bashrc”, and it does not source “~/.bashrc”.
See attached images with key diagnostics.
The first image shows what should happen on the left (from the Arch Wiki page on BASH), and what actually happens on the right. Note that the shell is non-login (shopt login_shell is unset) and interactive (note the “i” in $-). And yet, I have to source “/etc/bash.bashrc” and “~/.bashrc” manually:
The second image shows that the problem is not limited to Konsole. I also installed and ran “UXTerm”, “Terminal”, and “QTerminal”, and they’re all doing the same wrong thing. So it’s something deeper than a per-app issue:
So… what could be causing BASH to act in such an odd way on this one computer? I mean, sure, I can manually type “source /etc/bash.bashrc” and “source ~/.bashrc” each time I launch Konsole, but I shouldn’t have to.
Recent Manjaro KDE/Plasma installations come with zsh and also the default profile in the Konsole app is a read only profile perusing zsh.
To use bash, you need to create a new profile that uses bash and set this as default.
Simply changing the shell for the user or system wide (through chsh -s /bin/bash for example) has no effect in Konsole.
It’s a weird design choice IMO but that is how it is right now.
Other terminal apps like uxterm or xterm or any other do respect the setting of the shell through chsh -s - just not Konsole, not without changing the default profile.
Nope, that is not the problem here. The shell that’s being invoked is BASH, not ZSH. (The first thing I do on every computer is to change that in the default Konsole profile.)
Also, see my image #2. Those 4 terminals are “UXTerm”, “Pantheon Terminal”, “QTerminal”, and Konsole, and yet they’re all doing the same thing, so this isn’t a Konsole issue. And see all those “bash-5.1$”? That’s the default BASH prompt, not the default ZSH prompt, which looks very different, with reversed colors embedded in a block.
So the problem is not application-specific to any one terminal emulator; it’s something deeper.
… next speculation:
The output in the picture top right looks like the response to syntax errors in the files that are tried to be sourced.
Looks like some lines in these files need to be commented because they are invalid as they are - but are not commented.
Nope, those are diagnostic “echo” lines I added to make sure that if ‘/etc/bash.bashrc’ was being sourced, that the file ran to completion. And as you can see, when I manually sourced it, both the “at top” and “at bottom” echos printed.
But the problem was that ‘/etc/bash.bashrc’ and ‘~/.bashrc’ should have been sourced automatically, and yet, they weren’t.
But!!! See the comment I’m about to make at top level of this thread! (The situation changed for the better overnight.)
Ok, big update: This problem literally went away overnight.
The problem as it was last night: On launching BASH in any terminal emulator, since such sessions are “interactive non-login”, the files “/etc/bash.bashrc” and “~/.bashrc” should be sourced, but were not being sourced. It was as if all shells were being treated as “non-interactive non-login”.
The situation 24 hours later: The problem has disappeared! The files “/etc/profile”, “/etc/bash.bashrc”, and “~/.bashrc” are all now working correctly!
So I tried to reproduce the problem by doing a bunch of the same stuff I was doing last night, then restarting the computer:
editing “/etc/shells”
editing “/etc/profile”
editing “/etc/bash.bashrc”
editing “~/.bashrc”
But nothing reproduces the problem. Which I find annoying, because I’d rather know what was causing a problem, in order to prevent it in the future.
So, in short, the problem simply “went away”. I have no idea why it went away, or why the problem ever cropped up in the first place. Color me puzzled.
Interesting idea (“print shell inputs as they are received”), but ultimately doesn’t work for determining what files where sourced when launching a terminal that invokes a new interactive non-login instance of BASH, because “sourced” lines of text are not considered “input” lines of text. One needs to use “echo” lines and/or set-and-export environmental variables for that kind of debugging.
However, while looking-up what “bash --verbose” means, I came across “bash -i” which explicitly forces bash to consider an invocation as being “interactive” even when it otherwise would be inclined to assume otherwise (as was apparently happening to me on that one computer for still-unknown reasons). So I think I’ll change my terminal profiles to invoke “bash -i” instead of just “bash”, which will hopefully prevent this confusion from occurring again.
In addition to above, I had a couple of thoughts that might help in the future.
Check bash and options
shopt -p login_shell ( -u or -s)
echo $BASH $SHELL $-
ps -f (bash or -bash)
Any difference
Outcome on a TTY
Create a new user, open terminal…
Compare your files with /etc/skel/ (i.e., /etc/skel/.profile and/or .bash_profile). Not just content but ownership and permissions. /etc/profile can be compared to /usr/share/factory/etc/profile.
Make small changes and consider logon/off or reboot between changes
Confirm default shell & groups
grep $USER /etc/passwd /etc/group
Follow journal as you open another terminal and/or ~/.xsession-errors
journalctl -f
View journal to see what might have run “overnight”. Perhaps all it took was a reboot and/or a logoff/logon after “some” change to get things working
