[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