Re: customize Debian 11 evironment in lightdm (and in general?)
On Thu, May 05, 2022 at 06:48:49PM +0200, Giovanni Biscuolo wrote:
> I'm trying to customize my user environment when using the lightdm
> display manager (then the LXDE desktop environment)
OK.
> This is my ~/.profile:
>
> --8<---------------cut here---------------start------------->8---
>
> ### Guix settings
> #
> # add Guix current path
> export PATH="$HOME/.config/guix/current/bin${PATH:+:}$PATH"
> # Locale path
> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> # add Guix infopath
> export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
> # set default Guix profile
> export GUIX_PROFILE="$HOME/.guix-profile"
> # source default Guix profile
> . $GUIX_PROFILE/etc/profile
>
> --8<---------------cut here---------------end--------------->8---
Note that your .profile has NOTHING about XDG in it. (It's also not
sourcing ~/.bashrc which is bad, but maybe you simply never work in
a login shell, so you never noticed it.)
> and this is my ~/.xsessionrc:
>
> --8<---------------cut here---------------start------------->8---
>
> if [ -f ~/.profile ]; then
> . ~/.profile
> fi
>
> export XSESSION_WAS_HERE="Yes"
>
> --8<---------------cut here---------------end--------------->8---
OK.
> As shown above, the "env" result and the "systemctl --user
> show-environment" are slightly different,
That's not a surprise.
> in particular I'm missing
> XDG_DATA_DIRS as configured in my ~/.profile
XDG_DATA_DIRS is not configured in your .profile.
To this day I've never found an actual use for systemctl --user. It
runs things when you login, and those things operate in some sort of
pristine daemonic environment, kind of like a cron job, but not quite
as bare.
The fact that you've apparently found some use for it is a surprise.
Maybe some day I'll find one as well.
Anyway, the environment provided to things launched by systemctl --user
is not the same as your interactive session's environment.
> When I log in via lightdm to an LXDE session, I open LXterminal to check
> my environment and I find:
>
> patrizia@raifort:~$ env | grep XDG
> [...]
> XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/
> If in the LXTerminal I start a login bash shell with "bash -l" I get:
>
> patrizia@raifort:~$ env | grep XDG
> [...]
> XDG_DATA_DIRS=/home/patrizia/.guix-profile/share:/home/patrizia/.guix-profile/share:/home/patrizia/.guix-profile/share:/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/
> Now the XDG_DATA_DIRS is fine.
Interesting. I'm not familiar with LXDE or LXterminal. Did they follow
GNOME's lead? Is LXterminal spawned as child of some daemon like dbus,
instead of a child of your X session?
It certainly looks that way.
You have my pity.
(Also, it's not clear where your XDG_DATA_DIRS variable is actually
coming from. Is it from that $GUIX_PROFILE/etc/profile thing that's
dotted in from your .profile? Or is it from some other magical place?)
If you need to customize your *shell* environment when you're working
under a cursed desktop like GNOME (and apparently LXDE?) where the
terminal does not inherit the X session's variables, you might need to
seek out GNOME (or LXDE) people who have already tackled that problem,
and find out how they deal with it.
If you actually need to customize your systemctl --user environment, I
think there are manuals for how to do that. I believe there's a special
command that you can run to inject environment variables into the
systemctl --user daemon from outside. But it's been a long time since I
looked at that stuff, and it was never my primary intention to learn how
to configure systemctl --user. It was simply knowledge that I glimpsed
as a side effect of the thing I was actually trying to do (find a shell-
and DE-agnostic way to configure the login session). Which it turns out
is not a thing systemd supports.
> Is there a way to customize my environment in a standard way that works
> with all display managers and desktop environments?
(And shells. That's a big one.)
If there is, I have never found it.
The systemd/XDG people clearly do not care about this. They provide no
means of doing it. Their documentation doesn't even address the issue.
It's like the *concept* of a user customizing their own login environment
never occurred to any of them.
The GNOME people made it even worse, by launching their terminal as a
child of a daemon that is not part of the session. Nothing gets inherited
in the ways that a Unix user expects. Every new instance of gnome-terminal
has the generic, default, non-customized environment. The only way *I*
know of to change anything in that environment is to do it at the shell
level, *after* gnome-terminal has launched a shell. Because you can't
do it at the GNOME level, that's for sure.
Now, I don't know LXDE, but from your descriptions, it certainly sounds
like LXDE shares some of these characteristics with GNOME.
So, if you really do need to override the environment at the shell level,
you'd be looking at the ~/.bashrc file, assuming bash is your shell.
That's the file that bash reads when it's run as an interactive, non-login
shell -- which is what you should get when you launch an LXterminal,
for example. It's also the file that it'll read when you type "bash"
with no arguments, or when you do a shell escape out of a text editor,
or anything else that launches a shell in a normal way.
In a traditional Unix setup, all of your environment variables would be
set in ~/.profile which is read by your login shell, which is spawned
by login(1) when you login on your terminal. Then you can run 'startx'
or whatever, which starts an X session which is a child of your login
shell, and therefore inherits all of the stuff that was set in .profile.
The X session launches a window manager, and the window manager can
launch terminals on demand. The terminals inherit the environment from
the WM, which inherited it from the X session, which inherited it from
the login shell.
Your desktop environment clearly doesn't work that way, though.
Reply to: