"Brandon S. Allbery KF8NH" writes: [...]

I was thinking it would be nice to be able to specify a logfile for random program stdout/stderr.

That would do. Would be cleaner, IMHO, for the logHook output to go somewhere else. Then in a normal setup you'd get the logging from clients in .xsession-errors, whether those started before xmonad or by xmonad.

Bruce Stephens writes: [...]

That would do. Would be cleaner, IMHO, for the logHook output to go somewhere else. Then in a normal setup you'd get the logging from clients in .xsession-errors, whether those started before xmonad or by xmonad.

I guess the simplest way would be to use the more conventional arrangement of xmonad starting the program (whether dzen2 or something else) that displays the information?

Bruce Stephens writes:

Bruce Stephens writes:

[...]

...

That would do. Would be cleaner, IMHO, for the logHook output to go somewhere else. Then in a normal setup you'd get the logging from clients in .xsession-errors, whether those started before xmonad or by xmonad.

I guess the simplest way would be to use the more conventional arrangement of xmonad starting the program (whether dzen2 or something else) that displays the information?

Most of the programs by convention expect output from a sub-shell to also contain the output from the sub-shells within that sub-shell. Usually xdm or alike redirect those outputs from programs started by it and ~/.xsession and subsequent calls to ~/.xsession-errors. Normally, it's useless, but when something goes wrong, that is the first place to seek for insights. So I would think that redirecting the std{out,err} to /dev/null is bad. Since we can not force all other programs to make their own log files, the best way I believe is that to redirect the output of logHook. And I would suggest using FIFOs (named pipes) as a good solution for logHook to give its information to various displaying programs like dzen, xmobar or something similar. -- c/* __o/* <\ * (__ */\ <

Spencer Janssen writes:

The consensus seems to be that we should fix logHook rather than changing spawn.

Attached is a module providing a log hook that starts its own dzen. This is very kludgy but shows that it can be achieved. Use it by putting in Config.hs: import XMonadContrib.StatusBar logHook = statusBar defaultSBConf This log hook includes window titles, but in order for them to be updated properly Main.hs need to be hacked to call logHook on XPropertyNotify events. I achieve this with: hunk ./Main.hs 254 -handle e = broadcastMessage e -- trace (eventName e) -- ignoring +handle e = do + case e of + (AnyEvent {ev_event_type = t}) + | t == propertyNotify -> updateProperties + _ -> return () + broadcastMessage e -- trace (eventName e) -- ignoring hunk ./Operations.hs 253 + +updateProperties :: X () +updateProperties = logHook I hope this is of some inspiration to others. Toby.