Issue 415 in xmonad: xmonad assumes that the shell can find it in $PATH

Status: New Owner: ---- New issue 415 by nwfilardo: xmonad assumes that the shell can find it in $PATH http://code.google.com/p/xmonad/issues/detail?id=415 What steps will reproduce the problem? 1. Run xmonad by full path, not "xmonad", with xmonad not in $PATH 2. Attempt to restart xmonad; the exec will fail. What is the expected output? What do you see instead? By default, I would expect xmonad to use the paths baked in by Cabal, but perhaps there is reason not to. What version of the product are you using? On what operating system? 0.9.1, built from darcs. Debian sid. I'm attaching a first pass of a patch for this, but something seems wrong with it; why do I need to specify Paths_xmonad in the .cabal file? Attachments: cabalpaths.diff 2.8 KB

Updates: Status: Patch Labels: Component-Core Comment #1 on issue 415 by vogt.adam: xmonad assumes that the shell can find it in $PATH http://code.google.com/p/xmonad/issues/detail?id=415 I've previously listed Paths_$packagename, so I don't think that's wrong. Perhaps somebody else knows a reason to look at $PATH instead of $xmonad_bindir (or the path cabal installs it to)

Comment #2 on issue 415 by allber...@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.)
participants (1)
-
codesite-noreply@google.com