-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/etc/profile is never sourced when launching sway from GDM #3109
Comments
This happens because GDM doesn't start a shell. This is normal behaviour, and we can't do anything about it. Why do you need to source |
Hi, thanks for getting back so fast. The reason I wanted this sourced is that on Arch Linux, a bunch of environment vars get set by files in |
This shouldn't matter, because when you run |
Wait, this should work. What is your |
My understanding is that profile files ( I'm using zsh, but as you ask about
I also found this discussion of the same issue with relation to the same issue in Gnome under wayland. It looks like there they have some code inside of the |
Ah, right, this makes sense. GNOME has |
Yes, that sounds like a plan. Thanks for your help. |
Is there any working example? I tried:
Without success. |
I am using: Desktop file: [Desktop Entry]
Name=Sway (in login shell)
Comment=SirCmpwn's Wayland window manager
Exec=/usr/local/bin/sway-in-shell
Type=Application
#!/bin/sh
if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
[ "x$XDG_SESSION_CLASS" != "xgreeter" ] &&
[ -n "$SHELL" ] &&
grep -q "$SHELL" /etc/shells &&
! (echo "$SHELL" | grep -q "false") &&
! (echo "$SHELL" | grep -q "nologin"); then
if [ "$1" != '-l' ]; then
exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"
else
shift
fi
fi
exec /usr/bin/sway "$@"
|
I just tried that and it works. I have a |
I thought this I moved all reasonable environment definitions ( |
Is there any plan to support this officially in any way? Starting out interacting with a new WM by having to manually edit the .desktop file installed by the package manager isn't the greatest experience. Or is the correct solution to use another login manager - if so, which one? I feel like this should be supported in some sense because as I understand it, Apologies if this is a bit ranting - I appreciate sway existing, and I don't mean to rag on this one thing. Just a bit annoying to try a new thing & immediately run into a closed issue where the solution is modifying system files installed by sway. |
This is a display manager bug. Users logging in via fbcon get their profile sourced, the same should happen when running from a display manager. FWIW, display managers aren't officially supported by Sway because of bugs like this. |
Cool, thanks - that's what I wanted to know. |
Just discovered today this issue, after months (years ?) of using Sway + GDM, I didn't know if this is an issue even with another login manager too, like Lightdm. I discovered this issue while trying to run flatpack applications that should be already sourced on Arch under Anyway, I fixed with this custom desktop launcher: ❯ cat /usr/share/wayland-sessions/sway-shell.desktop
[Desktop Entry]
Name=Sway (in login shell)
Comment=SirCmpwn's Wayland window manager
Exec=zsh -l -c sway
Type=Application |
Due this issue: swaywm/sway#3109
Hi,
I found that when launching Sway from GDM on Archlinux, the
/etc/profile
file never gets sourced. I'm not sure if this counts as a bug, as the behaviour is the same for other wayland sessions that I tried, like Weston (but not Gnome, for some reason), and its only a problem when launching from a graphical login manager, as otherwise the profile is sourced already (e.g. when logging into a TTY). My sway version:To verify, you could do something like edit /etc/profile and add
export MY_VARIABLE=1
to that file. Then login via GDM with Sway, launch a terminal and check to see ifMY_VARIABLE
is set. In my tests, it is not.I have been able to solve this by changing the
Exec=sway
line insway.desktop
toExec=bash -l -c sway
. This launches a login shell (which sources the profile) and then runs sway inside of the shell. This is enough for my purposes, but I'm not sure if this is the correct way to fix this (or even if this warrants fixing) ... at any rate I figured I would report it.The text was updated successfully, but these errors were encountered: