[xmonad] Issue 415 in xmonad: xmonad assumes that the shell can find it in $PATH
codesite-noreply at google.com
codesite-noreply at google.com
Sat Feb 26 22:12:35 CET 2011
Comment #2 on issue 415 by allber... at gmail.com: xmonad assumes that the
shell can find it in $PATH
http://code.google.com/p/xmonad/issues/detail?id=415
I find it useful to be able to rename my xmonad for testing, when I have
reason to expect that my development will break it (I have a wrapper script
that does xmonad-test || xmonad, so I can killall xmonad from a console and
get the working one).
The standard way to deal with this is to look at argv[0], and use it as is
if it contains slashes or do a PATH search on it otherwise. This is
difficult in Haskell because getProgName trims everything to the
basename "for portability reasons" --- but there is also an additional
complication, whose resolution also fixes this problem.
The complication is that, when xmonad exec()s a customized xmonad, it needs
to pass on the path it was invoked by so that mod-q does the right thing
even if the user chooses to delete their xmonad.hs. But if you need to do
this, then the solution to the other problem is obvious: use a wrapper
which uses the same option to pass its argv[0] (or shell $0) to the real
xmonad. (That is, xmonad exec()s xmonad-bin exec()s user xmonad-platform.)
There are a couple of additional considerations here; in particular that
the user xmonad binary needs to use the original (base)name instead of a
hardcoded "xmonad" and therefore its xmonad.hs should also use that
basename (so it would be e.g. xmonad-test.hs).
(The wrapper might also check for $(basename $0)-bin and fall back to
xmonad-bin, and even run xmonad-bin if the custom one exits with an
error/signal, thereby making it do the same kind of debugging setup I
described above.)
More information about the xmonad
mailing list