Hyprland does not seem to source the same startup files as Gnome

Does anyone have any insight into the differences in what startup files Hyprland loads as opposed to default Gnome (this is in Tumbleweed). If I log in to Gnome, my $PATH includes ~/.local/bin and ~/bin. But when I load into hyprland, these are not included. It seems like /etc/profile has a part that does this, but is this not always sourced?

1 Like

/etc/profile is sourced by Bourne-compatible login shell like bash. It is not supposed to be sourced by random binary.

Hyperland is designed to be started from your login shell (which has sourced /etc/profile by definition). At least, this is the only way officially supported by upstream. If you start Hyprland differently, it is entirely up to you to configure it to do what you need.

It loads its configuration file (which IIRC is ~/.config/hypr/hyprland.conf) and does whatever this file tells it to do.

GNOME Session is launched by shell script which explicitly sources /etc/profile. Hyprland is not aimed at offering full Desktop Environment and so does nothing of the sort. Hyprland is barebone Wayland compositor which cannot be compared with GNOME Project (the comparable part is Mutter/GNOME Shell).

1 Like

@dooptydoo yes I launch hyprland here from a VT… on my standalone hyprland, it’s launched when logging in as my user to VT1, but I use seatd there…

So, as to how I’m starting hyprland. I’m just selecting it as my session in the display manager installed by default if you do a Gnome install (gdm??). So based on what you’re saying, that isn’t currently running a typical login shell? Is that something that should be expected, or is that a shortcoming on hyprland’s behalf?

I guess what I’m getting at is do I need to figure out why hyprland isn’t running from a login shell? Or do I accept that it’s supposed to be that way and setup some kind of script that establishes defaults I always want to be used in Gnome and in Hyprland?

I just don’t want to make duplicate configurations for things if there’s a more sensible way to do it.

Based on your response, considering I’m just using the default menu entry in my display manager, it seems like it really should be running from a login shell and therefore source /etc/profile, so on and so forth.

@dooptydoo so on my desktop with GNOME, I don’t have GDM/GNOME running, so I systemctl isolate multi-user.target login as my user and then start Hyprland

On my standalone system (MicroOS - boots to multi-user.target) I have;

cat /etc/profile.d/hyprland.sh 

if [ -z "${DISPLAY}" ] && [ "${XDG_VTNR}" == 1 ]; then
  exec Hyprland > /dev/null 2>&1
fi

So if want to do maintenance locally I just switch to a different VT other than 1 or ssh in…

This just starts Hyprland binary. Period.

“It” (if you mean session choice in display manager) just launches Hyprland binary. It does not start any shell at all.

Because nobody implemented it. What you have is “minimal efforts” implementation - it allows you to start Hyprland binary from your Display Manager. Nothing more.

If you really need something different - copy session definition, give it different name, make it to do whatever you like. Test it, submit to openSUSE package or upstream (depending on where session definition comes from).

I fail to see how you came to this conclusion.

Interesting. I guess my understanding of the linux boot process is lacking. In the case that you are using a display manager, is the dm itself not ran from a login shell? Such that things /etc/profile get sourced? Or is the login shell entered once you actually logged in?

Something I just thought of: I use the autologin option. I wonder if that makes a difference in how the session is loaded?

I guess this is a subject I need more understanding of.

Ok, so this is kind of what I was getting at when I was asking if this was a shortcoming of hyprland. Maybe I should have said “design choice” instead of “shortcoming”. I assume they leave it this way to give the most flexibility?

I guess there’s sort of two approaches or paradigms. One being that the default option or configuration should be the one that allows the most flexibility; two being that the default option or configuration should be the one that gives the most sensible defaults without tinkering.

I guess my assumption was that the hyprland package’s installation defaults would align more with the second, but it seems to maybe align more with the first. I get that it’s a totally different desktop environment (or lack thereof, whatever), but I sort of expected things like environment variables like PATH would be the same in either.

Ok, so you start hyprland manually AFTER you’ve logged in? I typically keep my /home partition encrypted, and to avoid typing in two passwords on every boot, I enable the autologin feature. I like that gdm works with gnome and hyprland/sway, since it seems to autologin regardless which one I used last.

It seems the simplest way to keep all these features working well together is to make my own session definition to run hyprland from a login shell? Or is that naive?

@dooptydoo up to you, I only ran hyprland on Tumbleweed to test Nvidia, all startup (exec) and env variables are configured in hyprland.conf.

Of course not. DM runs before any user has logged in. Its task is to authenticate user and start user login session.

No.

That you have to address to Hyprland developers.

Someone has to implement and maintain it. Do you volunteer?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.