Issue 359 in xmonad: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed
Status: New Owner: ---- New issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 What steps will reproduce the problem? 1. Bind a key combination to shellPromptHere 2. On workspace 1, spawn a slow-starting program, say opera, using shellPromptHere 3. Switch to workspace 2 What is the expected output? The program is placed on workspace 1 where I started the program. What do you see instead? The program shows up on the current workspace, #2. What version of the product are you using? On what operating system? xmonad-darcs and xmonad-contrib-darcs on Arch Linux. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. As a general question, how do I go about debugging issues like this? In particular, how do I write out debugging information to files/console/screen? Attachments: xmonad.hs 6.8 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #1 on issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 Since the X monad and the Query monad are MonadIO instances, I suppose it's easy to write to files. Is there a simple way to create a window and write to it? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #2 on issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 I think I've found the issue. The way SpawnOn works is by associating a managehook which will move the program to a specific workspace, with the program's pid. Say we want to execute opera, the pid we recorded is for "/bin/sh /usr/bin/opera". However, when manageSpawn comes to manage the spawned program, the pid it sees is for "/usr/bin/opera", different from what we recorded. Therefore, it does nothing, and opera is placed on our current window. This issues begs a question: why does spawnPID do a double-fork? Below is code from XMonad.Core: -- | spawn. Launch an external application. Specifically, it double-forks and -- runs the 'String' you pass as a command to /bin/sh. spawn :: MonadIO m => String -> m () spawn x = spawnPID x >> return () -- | Like 'spawn', but returns the 'ProcessID' of the launched application spawnPID :: MonadIO m => String -> m ProcessID spawnPID x = xfork $ executeFile "/bin/sh" False ["-c", x] Nothing -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Updates: Labels: Priority-Medium Type-Defect Component-Contrib Usability Comment #3 on issue 359 by vogt.adam: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 For tracing execution, you can use XMonad.trace if you have a MonadIO m => ..., otherwise you can use Debug.Trace.trace, which will print stuff when otherwise pure code is evaluated. This patch might be helpful: http://www.haskell.org/pipermail/xmonad/2009-September/008474.html But I can't comment on the need to fork processes x times. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #4 on issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 @vogt.adam, Thanks for your comment. The patch you're linking to does address the issue, but it's against pre-0.9.1. I don't know how to adapt it to the latest version. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #5 on issue 359 by vogt.adam: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 You could still use it with 0.9.1, here's how: darcs get --tag 0.9.1 http://code.haskell.org/XMonadContrib darcs apply --mark-conflicts path/to/patch $EDITOR xmonad-contrib.cabal And the only conflicts to resolve are the dependencies for xmonad (so keep them like 0.9.1, but add filepath or something). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #6 on issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 Please ignore my comment about spawnPID, it's not the culprit. I'll try to adapt the patch to the darcs version. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #7 on issue 359 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 It's kind of hard to fully wrap my head around Daniel Wagner's patch, so I created my own hack. Hope it's useful for other people. Attachments: tt 27.2 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Comment #8 on issue 359 by wil...@willem.vanlint.name: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 Were the previous patches rejected due to the portability of the procfs? Is this a won't-fix then?
Comment #9 on issue 359 by allber...@gmail.com: shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed http://code.google.com/p/xmonad/issues/detail?id=359 If it needs to look for children of the spawned process, two possibilities occur to me: (a) use ps; assume POSIX compliance, or test for BSDish vs. POSIX (b) there are portable libraries for this kind of thing, although the dependencies may get interesting (the most portable one I can think of is libgtop...). Off the top of my head, various Unix-like OSes and the normal ways to get at this information: * Solaris: libkvm or /proc (note that /proc is not the same as on Linux or *BSD) * *BSD, OS X: sysctl; libkvm is available for the *BSDs but not OS X * Linux: /proc; libkvm is available libkvm has the difficulty that it usually requires setgid kmem, so you'd need a setgid helper program. It would be better, both for this and for startup notification in desktop managers, if someone had had the sense to recognize that a variant of _NET_WM_PID that recorded and passed on the pid of the original process would be useful, but the free desktop folks seem to have missed that notion. (Hm; maybe the way to go from here is to look at how desktop managers do startup notification and borrow that. I believe it's a freedesktop.org standard.) http://standards.freedesktop.org/startup-notification-spec/startup-notificat... There's also a reference implementation which might be worth interfacing to or reimplementing in Haskell.
participants (1)
-
codesite-noreply＠google.com