Hi, I'm sorry I couldn't set the "In-Reply-To" header correctly here. I hope this doesn't mess the thread order.
I just wanted to add some information to this, and maybe we can work around this issue somehow on debian. I ran into this issue because I wasn't able to setup my PATH variable on sway. There, as far as I can tell, two recommended ways of setting up environment variables: using systemd's ~/.config/environment.d/*.conf files, and using ~/.pam_environment. ~/.pam_environment was disabled on Debian, to my knowledge, because of CVE-2010-4708[1], so that is not an option. Using systemd runs into an issue with how debian's `/etc/profile` overrides the PATH[2]. A common workaround for this, as I found, is to use ~/.profile to set PATH, but this didn't seem to work for me. The discussion in this systemd issue seems to revolve around GNOME, and the solution there was to use a login shell[3] when running GNOME. That explains why I couldn't use ~/.profile: the default sway.desktop does not use a login shell. I tried the two suggestions Birger Schacht gave (sorry again about the messy thread, but I'll quote here). [...] But you can configure sway to run the file by > adding an exec statement to your swaywm config: > `exec sh ~/.profile` or something similar should work. > > Adding this to `.config/sway/config` (if I understood the suggestion correctly) did not work for me. Even with an `export MY_VAR=1` in my ~/.profile the variable was not in the sway environment. Maybe the `exec` runs in a subshell or something > For setting environment variables like $PATH there are different > approaches how to set them when starting sway, [0] lists some of them. > > [0]https://www.reddit.com/r/swaywm/comments/gpzqcg/set_environment_variables/ > > The approach suggested here is having a `sway` script somewhere in your path that overrides the system's sway binary and sets the variable didn't work for me. I think exactly because at that point PATH is fixed to what is in Debian's /etc/profile. The only thing that did work for me was changing the `sway.desktop` file read by GDM to execute sway inside a login shell. This is similar to the GNOME solution (even though I'll be the first to admit the solution in [3] is much better and more complete). The attached patch fixed the issue for me, as sway is now running under a login shell (so I can use ~/.profile) This solution works, but I don't want to have this as a permanent solution for myself since it requires changing a package provided file. Since the workaround of needing to use ~/.profile is a result of the combination of two debian specific behaviours, what do you think about having this solution in the package? I know the patch I provide here is not perfect, but if you agree I can try to work on a solution similar to GNOME's, which supports other shells. Cheers, Flávio [1]: https://security-tracker.debian.org/tracker/CVE-2010-4708 [2]: https://github.com/systemd/systemd/issues/6414 [3]: https://gitlab.gnome.org/GNOME/gnome-session/commit/7e307f8ddb91db5d4051c4c792519a660ba67f35
From 9473a37c5b5f44485d07718adbe85ee2c194a1f6 Mon Sep 17 00:00:00 2001 From: Flavio Amieiro <amieiro.fla...@gmail.com> Date: Mon, 19 Apr 2021 16:08:27 +0200 Subject: [PATCH] Uses login shell on sway.desktop --- sway.desktop | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sway.desktop b/sway.desktop index 420db5aa..538fbffb 100644 --- a/sway.desktop +++ b/sway.desktop @@ -1,5 +1,5 @@ [Desktop Entry] Name=Sway Comment=An i3-compatible Wayland compositor -Exec=sway +Exec=/bin/sh -l -c sway Type=Application -- 2.30.2
