shellPromptHere from XMonad.Actions.SpawnOn doesn't work as claimed

[GoogleCodeExporter]

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?

Original issue reported on code.google.com by wei....@gmail.com on 21 Jan 2010 at 4:19

Attachments:

• xmonad.hs

[GoogleCodeExporter]

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?

Original comment by wei....@gmail.com on 21 Jan 2010 at 4:29

[GoogleCodeExporter]

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

Original comment by wei....@gmail.com on 21 Jan 2010 at 7:35

[GoogleCodeExporter]

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.

Original comment by vogt.a...@gmail.com on 21 Jan 2010 at 4:02

• Added labels: Component-Contrib, Priority-Medium, Type-Defect, Usability

[GoogleCodeExporter]

@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.

Original comment by wei....@gmail.com on 21 Jan 2010 at 7:12

[GoogleCodeExporter]

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).

Original comment by vogt.a...@gmail.com on 21 Jan 2010 at 7:54

[GoogleCodeExporter]

Please ignore my comment about spawnPID, it's not the culprit. I'll try to 
adapt the 
patch to the darcs version.

Original comment by wei....@gmail.com on 22 Jan 2010 at 2:59

[GoogleCodeExporter]

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.

Original comment by wei....@gmail.com on 22 Jan 2010 at 6:02

Attachments:

• tt

[GoogleCodeExporter]

Were the previous patches rejected due to the portability of the procfs?
Is this a won't-fix then?

Original comment by wil...@willem.vanlint.name on 5 Aug 2011 at 7:39

[GoogleCodeExporter]

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-notification-
0.1.txt
There's also a reference implementation which might be worth interfacing to or 
reimplementing in Haskell.

Original comment by allber...@gmail.com on 6 Aug 2011 at 12:30