After 2024-02-21 Stable Update ~/.profile file is no longer sourced

After today’s stable update: [Stable Update] 2024-02-21 - Kernels, KDE, VirtualBox, Calamares, ROCm, Firefox, Thunderbird

I found out that the variables set in the ~/.profile file were no longer applied (eg the variables EDITOR and QT_QPA_PLATFORMTHEME), because executing echo $VARIABLENAME in a Terminal window, reports nothing.

At the moment I solved by adding source /home/dave/.profile inside ~/.bashrc.
I have no idea what is changed, to cause having the file ~/.profile not functional.

3 Likes

I experienced the same behavior and referenced this thread in:

1 Like

Could be due to this patch to LightDM:

https://gitlab.archlinux.org/archlinux/packaging/packages/lightdm/-/commit/75c048cabfe9693749f5f363ab6257400d954ffa

So for Bash, /etc/lightdm/Xsession does not directly source /etc/profile and ~/.profile any more, but instead spawns a shell in --login mode. According to the Bash reference manual:

When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

In other words, /etc/profile is still sourced as usual, but ~/.profile is only sourced if neither ~/.bash_profile nor ~/.bash_login exist.

On a fresh Manjaro Xfce, the bash package provides /etc/skel/.bash_profile, which takes precedence over /etc/skel/.profile from the manjaro-xfce-settings package. Thus, anything in ~/.profile will not see the light of day.

By the way: The above breaks theming of Qt5/6 apps, because QT_QPA_PLATFORMTHEME is exported from ~/.profile.

My workaround:

cd $HOME
ln -s .profile .xprofile

This works because /etc/lightdm/Xsession still unconditionally sources ~/.xprofile.

2 Likes

I had the same issue, and this workaround indeed fixed it for me, too! Thank you!

Well… partly…
My environment variables are being set properly again.
However, the additions to my PATH that I do in my .profile still don’t work anymore.

I use this for adding to my PATH:

# Path additions
pathadd() {
	for ((i=$#; i>0; i--));
	do
		ARG=${!i}
		if [ -d "$ARG" ] && [[ ":$PATH:" != *":$ARG:"* ]]; then
			PATH="$ARG${PATH:+":$PATH"}"
		fi
	done
}

pathadd \
	"/home/technicjelle/Build/darkhttpd" \
	"/home/technicjelle/Projects/Bash/" \
	"/home/technicjelle/.local/share/JetBrains/Toolbox/scripts" \
	"$ANDROID_HOME/tools" \
	"$ANDROID_HOME/tools/bin" \
	"$ANDROID_HOME/platform-tools" \
	"/opt/flutter/bin"

But it doesn’t apply:

$ echo $PATH | sed 's/:/\n/g'
/home/technicjelle/.local/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/sbin
/opt/cuda/bin
/opt/cuda/nsight_compute
/opt/cuda/nsight_systems/bin
/opt/flutter/bin
/usr/lib/jvm/default/bin
/usr/bin/site_perl
/usr/bin/vendor_perl
/usr/bin/core_perl
/usr/lib/rustup/bin

I suppose it used to be loaded via bash or zsh or something, but now it doesn’t?

Maybe if you export the variable?

1 Like

Apparently, your .profile is sourced again, because you have your environment variables back. Also, your pathadd() function works as intended when I add it to my ~/.profile script.

What happens if you add

export MYPATHBAK=$PATH

to the end of your .profile, log out and back in, and then invoke

$ echo $MYPATHBAK

on a bash prompt?

1 Like

It seems to be empty…
A screenshot of my terminal window, with “echo $MYPATHBAK” printing an empty line:

Earlier, I already tried to touch a new file in a specific place in my home directory from inside the .profile, too, to verify that the thing even runs at all, but that also didn’t work.

Maybe the script just crashes halfway through or something?

EDIT: I’m now pretty sure it does crash for some reason…
I have added export MYPATHBAK1=$PATH before the function definition, export MYPATHBAK2=$PATH before calling the function, and export MYPATHBAK3=$PATH at the end.
Both 1 and 2 are properly copied in, but 3 is empty.

Hello everyone,

I also encountered the same issue after the recent stable update. It seems that with the removal of the bashrc-manjaro package and the merging of bash configuration files in the bash package, the .profile file is no longer being sourced automatically.

To resolve this issue, I added the following line to my .bash_profile:
[[ -f ~/.profile ]] && . ~/.profile

This line checks if the .profile file exists and sources it if it does. After making this change, my environment variables set in the .profile file are now being applied correctly.

3 Likes

Does this fix only run when you open a terminal, inside that terminal? Or does it run at login, for all processes?
Because putting env vars in the bashrc, for example, only make them work inside that terminal instance, and not outside.

Also, does this work if I use zsh instead of bash as my default shell?

  1. The fix provided in the .bash_profile file ensures that the .profile file is sourced at login, making the environment variables available for all processes, not just within the terminal instance. By sourcing .profile at login, it ensures that the environment variables are set globally for the user session.
  2. Regarding your second question, if you use zsh as your default shell instead of bash, the .bash_profile file will not be sourced automatically. However, you can achieve the same effect by adding the sourcing command to the equivalent file for zsh, which is typically .zprofile or .zshrc depending on your configuration.
1 Like

Thanks for the info!
I was finally able to solve my issue!
Though I didn’t solve it the way I expected I would…

For some reason, I thought to try running my .profile folder with zsh: $ zsh ~/.profile
And it gave a kind of syntax error on the pathadd function I had!
Which seemed to check out with my theory from my last comment, where I thought it was maybe crashing somehow.
And indeed, after a rewrite of the function, it all works exactly like it should again!
I don’t know where I got that pathadd function from anymore, but I was able to replace it with something much simpler:

pathadd() {
	for var in "$@"
	do
		PATH="$var":$PATH
	done
}

Sorry for wasting your time, everyone… :sweat_smile:

Welcome to Manjaro forum @edyatl

Suggested solution is working for me and other Xfce users

But issue is not caused by bashrc-manjaro

There is no mention of an issue with lightdm in Stable update announcement so I can see how it could be assumed to relate to the known Issue with bashrc-manjaro

This has been the simplest and clean solution for me.