been looking for this for a long time!
We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
Recommending means this is a discussion worth sharing. It gets shared to your followers' Disqus feeds, and gives the creator kudos!
I see warnings:
```
Copied executables to /home/ashesh/.local/bin:
- xmobar
- xmonad
Warning: The xmobar executable found on the PATH environment variable is /usr/bin/xmobar and not the
version that was just installed. This means that xmobar
calls on the command line will not use this version.
Warning: The xmonad executable found on the PATH environment variable is /usr/bin/xmonad and not the
version that was just installed. This means that xmonad
calls on the command line will not use this version.
```
Which probably means that I need to symlink the stack generated executables to the ones indicated in the path, but doing updates keeps breaking that.
Do you *also* have xmonad and xmobar installed in /usr/bin? That is, do you now have two different versions of xmonad/xmobad installed: one in /usr/bin (installed using your OS's package manager, for example), and another in (say) $HOME/.local/bin (installed using stack)? If so, remove the packages that were installed into /usr/bin.
In Arch Linux, you can use pacman to query which package owns a file:
$ pacman -Qo /usr/bin/xmonad
and then remove that package. I assume that other distros' package managers have a similar functionality.
Thanks for the quick reply, Brian. Yes, in my first attempts on Manjaro, I installed xmonad and xmobar directly using pacman. Realising that things were broken with that install, I followed your instructions, but didn't remove the packages previously installed.
I'm not sure what the correct process here should be: I can remove these packages from my system, but will that also mean I can still use xmonad as my session on lightdm? I'm not sure where lightdm looks to determine the available WMs on a system but maybe I should look into that.
You should remove them from your system.
I don't use a display manager, but it looks like lightdm uses *.desktop files located in /usr/share/xsessions. For example, the xmonad package from the official repos installs a file /usr/share/xessions/xmonad.desktop that looks like this:
[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Xmonad
Comment=Lightweight X11 tiled window manager written in Haskell
Exec=xmonad
Icon=xmonad
Terminal=false
StartupNotify=false
Categories=Application;
I imagine you could create this exact same file, simply changing the Exec line to:
Exec=/home/ashesh/.local/bin/xmonad
(You might not even have to do that -- it depends on whether lightdm has access to your PATH or not. It looks like lightdm is not started from a shell, so that may not be the case. If I were you, I'd first try using this exact xmonad.desktop file as is, and if it can't find xmonad, then use the full path name to the xmonad binary.)
Thanks again for taking the time to respond. This worked like a charm.
One caveat though: somehow symlinking the xmonad.desktop file from elsewhere under ../xsessions didn't really work. Lightdm was still showing only the other DM/WM's as available sessions. Copying the file does the trick.
Also: this seems to break `xmonad --restart` for some reason.
Thanks for this! I've installed xmonad using your method on Arch Linux. Everything works wonderfully, other then `xmonad --restart` doesn't seem to work anymore. I have to log out and back for recompiles to take effect. Any ideas?
Did you do step 6? What is the output of `xmonad --restart`?
Yeah, I wrote the build file and set it to executable. `xmonad --restart` doesn't seem to do anything. It returns instantly with no output to stdout.
I'm having the same problem.
xmonad --recompile seems to work but xmonad --restart doesnt apply changes.
I have to logout
I'm seeing the same on my side. Mod + Q doesn't have any effect whatsoever.
Also, strangely enough, if you symlink ~/.local/bin/xmonad to /usr/bin, it seems to "fix" the problem.
After a little bit of digging through, I think its just a matter of the PATH variable being correctly set; see https://github.com/xmonad/x...
Interesting. That might be an indication that you did not add ~/.local/bin to your PATH. Did you follow this last part of Step 5?
"NB: You’ll want to add ~/.local/bin to your PATH, if it isn’t already."
Yeah, its added to my .bashrc and .xinitrc, but that seems to have no effect on this.
But xmonad --recompile works when you use startx (i.e. not lightdm), right? So it must have something to do with lightdm. Maybe running xmonad from lightdm is like running it as root, and so running xmonad --recompile puts the xmonad binary into /usr/bin (root's binaries) instead of ~/.local/bin (user's binaries). If so, then if you run lightdm by executing ~/.local/bin/xmonad, then recompiling won't update your session (because lightdm is looking at ~/.local/bin/xmonad, not /usr/bin/xmonad, and it's the latter that is being rebuilt), whereas if you run lightdm by executing /usr/bin/xmonad (symlinked to ~/.local/bin/xmonad), then recompiling will update your session.
You could test this by deleting the /usr/bin/xmonad symlink, editing your lightdm to execute ~/.local/bin/xmonad, logging out and back in, and recompiling. If you see that /usr/bin/xmonad has been created, then xmonad is recompiling itself 'as root' instead of 'as user'.
Also, when /usr/bin/xmonad is not present, I see this in my .xsession-errors:
```
/bin/sh: line 0: type: xmonad: not found
/bin/sh: xmessage: command not found
```
Which basically means the executable was not on the path. What fixes the problem is adding the path to ~/.profile as well, which makes it available to the entire desktop session.
Alright, thanks for this. I've added a new section, Step 9, for people with login managers, which I hope clarifies all of this.
You're welcome, and thanks for adding the additional step.
I tried that but that doesn't do anything. I can log into xmonad but mod + q stays broken. It only seems to work when there's a /usr/bin symlink which is strange. I've also add this to the path in /etc/environment but that also seems to have no effect.
I'm leaning towards https://github.com/xmonad/x... not being able to find xmonad in the path.
I'm having a bit of trouble for this to compile, I think it's possibly to do with the version of GHC that stack installed, but I've been unable to confirm this. When I do `stack install`, it fails with this error:
```
/tmp/stack22715/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0 configure --with-ghc=/home/mlopes/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/bin/ghc --with-ghc-pkg=/home/mlopes/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/pkgdb --libdir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/lib --bindir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/bin --datadir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/share --libexecdir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/libexec --sysconfdir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/etc --docdir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/doc/network-2.6.3.2 --htmldir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/doc/network-2.6.3.2 --haddockdir=/home/mlopes/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.10/8.0.2/doc/network-2.6.3.2 --dependency=base=base-4.9.1.0 --dependency=bytestring=bytestring-0.10.8.1 --dependency=unix=unix-2.7.2.1
Process exited with code: ExitFailure 1
Logs have been written to: /home/mlopes/.xmonad/.stack-work/logs/network-2.6.3.2.log
[1 of 2] Compiling Main ( /tmp/stack22715/network-2.6.3.2/Setup.hs, /tmp/stack22715/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/Main.o )
[2 of 2] Compiling StackSetupShim ( /home/mlopes/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack22715/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/StackSetupShim.o )
Linking /tmp/stack22715/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/setup ...
Configuring network-2.6.3.2...
configure: WARNING: unrecognized options: --with-compiler
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/tmp/stack22715/network-2.6.3.2':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
```
this also happens to something called `old-time` and to `X11-1.8`. I wonder if you have any idea of what could be going on?
EDIT: Editing ghc settings as suggested on this thread, seems to have worked:
https://github.com/commerci...
Thank you, worked perfectly. As a Haskell novice, I've unsuccessfully battled this one many times!