PATH and graphical sessions
- Login o registrati per inviare commenti
I am a translator!
In a plasma (KDE) wayland session opened right after boot, I have:
echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
If I open a GNOME wayland session, close it and open a plasma wayland session again:
echo $PATH /home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Opening a GNOME wayland session is so fast that I can't measure the time it takes (whereas plasma takes about 25 seconds to start!) so it isn't a terrible burden to open and close a GNOME wayland session first to get the right PATH, but I wonder whether there is a way without doing that.
Besides, the more I open and close sessions the longer PATH becomes, with many things there repeated, for example:
echo $PATH /home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
I never tried tweaking the PATH variable so this is coming from things automatically installed.
I see that my .profile is adding ~/bin et ~/.local/bin but for some reason it wasn't executed when I started a plasma wayland session. I believe that /etc/profile.d/guix.sh is what sets the pathes for guix, so it also wasn't executed.
I don't know how to check what triggers the execution of the files in /etc/profile/ and ~/.profile, and I am surprised that the contents of PATH set in previous sessions persists in another session, it looks like a bug.
I am a translator!
I added my .bashrc, .profile and the whole contents of /etc/profile, which I guess is what is relevant to this (I had it prepared and selected but I tend to forget that having the file selected is not enough, one needs to click on the "attach" button).
| Allegato | Dimensione |
|---|---|
| init.tar.gz | 2.41 KB |
I personally use GNU Bash (by default in Trisquel) and add the $HOME/Travail/bin directory to PATH with that line in ~/.bashrc:
PATH="$HOME/Travail/bin:$PATH"
I think use one of
export PATH="$HOME/Travail/bin:$PATH"
declare -x PATH="$HOME/Travail/bin:$PATH"
I am a translator!
I could do that but when opening a session in a number of graphical environments, everything is set properly in PATH already, including for programs installed by guix.
Besides, when the PATH is not set for guix, XDG_DATA_DIRS (and other variables) is also not set for guix, and also not for flatpak. I see that /etc/profile.d/guix.sh is setting everything properly for guix, and there is also /etc/profile.d/flatpak.sh setting XDG_DATA_DIRS for flatpak, and there are other .sh files in /etc/profile.d/ for other things, and when PATH is not only what is in /etc/environment (seems to be the system default), all the variables are set according to all files in /etc/profile.d.
So it looks like either /etc/profile is not sourced in some cases, or it is but something fails at some point so that at least guix.sh and flatpak.sh are not executed, or could there be another reason?
When the PATH (and other variables are not set), apps installed by guix are not visible in the menus of KDE, but apps installed by flatpak are visible still. I don't know how KDE does to create its menus, whether flatpak apps do something for them to persist even when the environment is not fully set.
found blog post
https://noah.meyerhans.us/2020/07/07/setting-environment-variables-for-gnome-session/
$ cat .config/systemd/user/gnome-shell-wayland.service.d/path.conf
[Service]
Environment=PATH=%h/bin:%h/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Is it work in your wayland?
I am a translator!
Thanks for the idea. Apparently, in KDE, this gnome-shell-wayland.service is not used.
Looking at https://userbase.kde.org/Session_Environment_Variables, I just tried:
mkdir -p ~/.config/plasma-workspace/env/ ln -s /etc/profile.d/* ~/.config/plasma-workspace/env/
Then, after closing and reopening the session, it looks a number of things are working now. However, I just had a strange situation (only Super and Ctrl+function key were working on the keyboard, click via touchpad not working but swipe working) that made me kill the session (using "sudo systemctl restart gdm.service"), I don't know whether that is related to this, I'll see if that happens again.
What if you create a file /etc/environment and put PATH=... there? Will it set path for your KDE?
Is there a reason to avoid prepending directories to PATH in ~/.profile (and not have ~/.bash_profile or ~/.bash_login, as explained at the beginning of ~/.profile)? That works and looks simpler (no need for administrative privileges).
I not sure if Wayland looks into ~/.profile or not. I think try everything and see what works for Wayland.
I use GNOME on Wayland on Trisquel 11. It works here to add directories to PATH in ~/.profile. Including with the command prompt you get with Alt+F2.
I am a translator!
I have added custom environment variable to my ~/.profile, with
export MYTESTVAR="aaa"
I opened a plasma wayland session after boot, the variable was not defined. I closed the session and opened a GNOME wayland session, the variable was defined. I closed that session and opened a wayland session again, the variable was defined. I don't know whether it is because it persists in some way, or whether something has changed that makes ~/.profile being sourced when opening the KDE session.
I don't know which process is sourcing ~/.profile or /etc/profile, and I am not sure whether it sources both or not.
The settings for guix are in /etc/profile.d/guix.sh. Everything in /etc/profile.d/ is sourced by /etc/profile. I reported that I previously used the trick of opening and closing a GNOME wayland session first, and that it worked, but once, I opened a GNOME wayland session and KDE again and the guix environment was not in place. I did not write this down so my memory may not be correct, but I think the guix variables (and flatpak and all) were not set even in the GNOME session.
So it looks like I am still not able to determine the exact circumstances in which a variable defined in ~/.profile is set or not. Perhaps the sourcing of ~/.profile and /etc/profile is actually not dependent on the type of graphical environment that is used to open a session, I don't know whether this could be gdm (which I am using) or another program that does not depend on the selected graphical environment.
So the twin giants Plasmo and Gnomo are stepping on each other's feet, and Guixo is taking the heat? If I am not mistaken, your setting involves systemd + gdm + wayland + gnomeshell + guix vs. systemd + gdm + wayland + plasmashell + guix. I would try installing Triskel on a VM, see if the situation is different, and if so, see which settings are different.
There is a documented attempt to improve Guix integration on "foreign" distros [1]. It is a bit less ambitious than your setting, but it looks like it still got some unexpected behavior with all DEs. It also has a specific comment about Triskel 10.
I am currently almost exclusively using LXDE and the Trisquel repo, from a clean Trisquel Mini 11 install, so obviously I live in a corner of the world where these integration hickups sound like bogeyman stories. At least, you are not "seeing a splash screen with a spinner for a while, then the screen goes black [2]".
[1] https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f
[2] https://lists.gnu.org/archive/html/help-guix/2022-05/msg00147.html
I am a translator!
So the twin giants Plasmo and Gnomo are stepping on each other's feet
My current assumption is simply that ~/.profile and /etc/profile are not sourced in the plasma wayland session.
Actually, I am not trying to mix Plama and Gnome. Xorg crashes quickly on my newest laptop and I suspect there are gradually less people willing to spend time debugging Xorg, so I decided to try environments using Wayland, and so far I had no similar issue on them. After trying Gnome, I tried Plama and found it much easier to use and configure using only software from Trisquel repository (including automatic tiling) so I don't plan to use Gnome anymore, I was just comparing with Gnome when investigating this issue.
Your idea of the VM is good, I will try it but without Gnome. If ~/.profile and /etc/profile are not sourced, one solution that should work is to create symbolic links to them in ~/.config/plasma-workspace/env. I have a few other small annoyances with Plasma on wayland, like ssh-agent not started automatically and the keepassxc icon missing from the panel (but if I open keepassxc and in its options, untick that option and click ok, then tick it back and click ok, it appears and remains for the rest of the session), that I could investigate too.
I am currently almost exclusively using LXDE and the Trisquel repo, from a clean Trisquel Mini 11 install, so obviously I live in a corner of the world where these integration hickups sound like bogeyman stories.
I use MATE with dwm on other computers, and with dolphin with previews of pdf files, which I have not managed to have with any other file manager. So KDE has the nice properties of providing everything and looking easily usable in general, so I could probably recommend it.
There is in fact an open guix issue report about the glitch with KDE Plasma: https://issues.guix.gnu.org/56050.
> previews of pdf files, which I have not managed to have with any other file manager.
Now this is a bit surprising. PCManFM has a hard-coded 32 MB file size limit for previews, but I do not recall any issue with Caja. You may need to check that the value for the file size limit is set high enough. But maybe it also depends on which pdf viewer you are using? The thumbnails have to be fetched somewhere, and I have now noticed that Caja has a specific "Atril properties" extension that is selected by default and may be taking care of just that.
EDITED UPDATE: installing Atril on Trisquel Mini made pdf preview thumbnails available in PCManFM. After swapping back to Evince, only the thumbnails that had been generated by Atril earlier were displayed, new pdf files did not get a preview. So Evince is just not doing its thumbnailing job properly when paired with PCManFM, even if it can be found in usr/share/thumbnailers. I have now swapped forward to Atril, and all is swell.