Environment var loading has limited functionality

[c4rlo]

The README says:

On startup environment is prepared by:

• sourcing shell profile
• […]

It looks like this is implemented by sourcing /etc/profile and ~/.profile. However, those are not the only places where environment variables are commonly set. In particular, I had been using .bash_profile for this, so this wasn't working. I was able to work around this by symlinking .profile -> .bash_profile.

The next issue was that my .bash_profile sets some variables conditionally, only in the case where a Wayland session is going to be started, i.e. behind the if uwsm check may-start check. Those variables also weren't being picked up by the current logic; I worked around this by setting them unconditionally.

So what I'd suggest is:

• Better docs on how startup env is obtained from shell profile
• Perhaps advising users to prefer using uwsm-env as the best way to set env vars

Another thing to think about: should uwsm start import the env vars in place at that time? That's what one might naively expect to happen.

Happy to help with this once a direction is agreed.

[Vladimir-csp]

~/.profile is a shell-independent location, and it is sourced by bash if ~/.bash_profile does not exist:

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.

Symlinking might not be the best idea here. If you do not have bash-specific things in profile, just use ~/.profile and remove ~/.bash_profile. If you have bash-specific things, put . ~/.profile in ~/.bash_profile.

uwsm start just generates and activates units, environment handling is done from inside wayland-wm-env@.service, which is not an environment uwsm start may start in, hence the may-start check, it should fail there by design.

I would prefer to not mess with any shell-specific handling, as the shell code used in uwsm is to the best of my knowledge POSIX-compliant.

I'll add a descriptive variable in preloader shell context so it can be used in conditions. How about IN_UWSM_ENV_PRELOADER=true?

if [ "$IN_UWSM_ENV_PRELOADER" = "true" ]; then
    do_something
fi

[c4rlo]

Thanks, that is very helpful. Your proposed enhancement sounds great to me.