Create symbolic link from ~/.local/bin/xmonad to /usr/bin/xmonad for login managers

[NapoleonWils0n]

if you are using a graphical login manager you need to create a symbolic link
from ~/.local/bin/xmonad to /usr/bin/xmonad otherwise the login manager wont login to xmonad

Because login manages wont search a users path for binaries

Maybe the docs could be updated to include a section about building xmonad with stack
and creating a symbolic link to /usr/bin/xmonad when creating the xmonad.desktop file

heres my notes about installing xmonad with stack and creating the xmonad.desktop file and symbolic link

https://github.com/NapoleonWils0n/cerberus/blob/master/xmonad/xmonad-ubuntu-stack-install.org#create-a-symbolic-to-usrbinxmonad

I also made a tutorial about installing xmonad with stack on youtube
https://www.youtube.com/watch?v=XvKAiR403O0

[liskin]

We're definitely not going to tell users to symlink contents of their home directory into /usr/bin. because that's bad practice.

We might want to clarify how users are supposed to ensure ~/.local/bin is in $PATH at the time ~/.xsession is executed, although I'm somewhat convinced this isn't really our problem… The distro's documentation should cover that. :-/

[geekosaur]

But there are distros which package xmonad with a session file of its own. This said, that's kinda their problem since they also should ship /usr/bin/xmonad. But users installing directly may be confused by the lack of similar session file, so we should at least document use of an .xsession-based session and mention the $PATH issue and to check the distro docs.

(I use a session file but it points to a local wrapper script that handles things like setting $PATH. It's not really intended for public distribution, though; among other things, it integrates with my dotfiles repo.)

[NapoleonWils0n]

HI Mate, creating a symlink was just a quick fix so that xmonad would work with a gui login manager

I have ~/.local/bin in my path but a login manager only checks the system path
so it doesnt pick up xmonad in the users path and just returns to the login screen

I couldnt find any documentation about getting the stack install of xmonad to work with a gui login manager
so creating a symlink was the easiest solution to get it working

I made a video about installing xmonad with stack and a viewer asked me to raise an issue on github
about getting the xmonad stack install to work with gui login managers

because they couldnt get it to work without the symlink fix that i use,
and wanted to help other people by updating the documentation

The issue for the end user is that they follow the guide and install xmonad with stack,
and create a desktop file and then try and login and keep getting returned to the login screen,
it doesnt look good

I understand creating a symlink may not be best practice but its quick it works and does the job

I do think the install page needs to provide some solution to this issue that works across distros,
and i honestly dont think expecting every distros documentation to cover the issue is going to happen,
because its quite a obscure issue

If there is a more elegant way of fixing the issue than using a symlink id be more than happy to test it out
and make a video about the "proper" way to resolve the issue

Not knocking you guys and your work

I just couldnt find any documentation on how to resolve the issue anywhere online other than creating a symlink

[liskin]

Maybe we should just tell people to use absolute path in their ~/.xsession. In your case, however, adding some export PATH=$HOME/.local/bin:$PATH to your ~/.xsessionrc might help, too.

[NapoleonWils0n]

HI Mate, im pretty sure i tried adding the full path to a xmonad.desktop file in /usr/share/xsession and it didnt work
ill have to double check

also i think xsessionrc is debian specific and so wont work on distros like arch, fedora and freebsd

[geekosaur]

~/.xsession is the standard name for a session startup file, cross-platform. I think only Fedora changes this, and even then you can still use the standard name; they just prefer you use their system-wide session default that then uses a different name for the stuff in ~.

What will guaranteed not work in a session file are environment variables and ~/~username; it must be an actual full path.

[NapoleonWils0n]

Hi Mate, ill play around with xsessions file
maybe its an ubuntu issue but creating a xmonad.desktop file in /usr/share/xsessions
with exec $HOME/.cache/xmonad/xmonad-x86_64-linux

worked on one machine running ubuntu but not another machine running ubuntu

[geekosaur]

As I mentioned, environment variables (such as $HOME) do not work in session files. That is why the one I linked to earlier says /home/allbery instead of $HOME.

[slotThe]

I'm reopening because I think something should happen—if only a note from our side that users should be aware of this

[geekosaur]

Worth noting here is that session files are generally read by the display manager at its startup, so per-user things are not available (hence no environment variables and only the system default $PATH).

[NapoleonWils0n]

I made a video about xmonad and xessions files explaining some of the issues i came across

as well as using xmonad-x86_64-linux instead of xmonad in your xsession file
so you dont have to recompile every time you login in, which is useful on older hardware

https://www.youtube.com/watch?v=3Bndp9XxvLU

[liskin]

Worth noting here is that session files are generally read by the display manager at its startup, so per-user things are not available (hence no environment variables and only the system default $PATH).

Which is why we recommend using a xsession .desktop file which invokes /etc/X11/Xsession (or its equivalent in other distros) which then invokes ~/.xsession (or its equivalent in other distros), allowing users to either use an absolute path (exec ~/.local/bin/xmonad) or override PATH.

[slotThe]

Which is why we recommend using a xsession .desktop file which invokes /etc/X11/Xsession (or its equivalent in other distros) which then invokes ~/.xsession (or its equivalent in other distros), allowing users to either use an absolute path (exec ~/.local/bin/xmonad) or override PATH.

That only works so long as you don't want to start other wm's with your login manager, right? If one wants multiple options (for whatever reason) then putting exec xmonad in your ~/.xsession doesn't really sound possible

[geekosaur]

That is however the traditional way of doing things.

There's also the RHEL/Fedora trick of having a session which copies /etc/X11/Xsession but reads ~/.Xclients and then runs a particular window manager. (In a modern setup this would be /etc/X11/Xsession.d but ignore all 90 tier files, I think.)

[slotThe]

We've had this come up on IRC more than once now—I'd still like to suggest something in case people want to have multiple options for a wm in their display manager

[MuhammedZakir]

Doesn't creating a .desktop session file in /usr/share/xsessions/ with Exec set to the absolute path of xmonad (/home/<username>/.local/bin/xmonad) solve this problem?

[geekosaur]

It does, but you can't put that in a cabal or stack package. OS distributions, on the other hand, can.