In XDG mode, per the XDG spec executables are not to be stored in config file locations. Since it can be regenerated from `xmonad.hs` when needed, it belongs under `.cache`. In legacy mode (~/.xmonad) the executable is kept next to the `xmonad.hs` file.

Your description of running `startx` seems a bit confused to me. Did you run it in the background and then try to run xmonad? This won't work because `startx` can't alter the environment variables of the running shell, so `$DISPLAY` won't be set. You need to run xmonad within the client environment: `startx ~/.cache/xmonad/xmonad-x86_64-linux` (it has to be a full pathname; see the `startx` documentation).

On Sun, Oct 22, 2023 at 3:03 PM Jan Detke <jandetke@outlook.com> wrote:
Brandon Allbery <allbery.b@gmail.com> writes:

> I'm looking at that page, and aside from one slight documentation bug that
> doesn't really affect anything here it looks correct to me and shouldn't be
> able to get the wrong executable name unless something has gone wrong
> inside xmonad's compile logic. Although that also looks out of date: we
> support stack building directly, so xmonad should use essentially that
> build script itself when it sees a `stack.yaml` file.
>
> You probably want to use the latest version of the install documentation:
> https://github.com/xmonad/xmonad/blob/master/INSTALL.md#build-using-stack
>
I found the executable under '$HOME/.cache/xmonad/'. Is this the intendet location for the executable? I assumed that it would reside in the directory where my xmonad.hs and the build script are located.

Additionally, I tried starting xmonad outside of my display manager that did not work out. I will look deeper into xinit for this regard - but as a short notice: I loggend in a tty, ran startx (with some warnings) and then xmonad. The received output was 'xmonad-x86_64-linux: user error (openDisplay)', which indicates that the xserver is not running properly.

I will try to fall back to my display manager by creating a desktop entry for xmonad under '/usr/share/xsessions/', but that is a task for tomorrow.

Thanks again
Jan


--
brandon s allbery kf8nh
allbery.b@gmail.com