On Sun, Dec 07, 2008 at 11:06:59AM +0000, Anselm R Garbe wrote:
> 2008/12/7 Neale Pickett <[EMAIL PROTECTED]>:
> > Guillaume Quintin <[EMAIL PROTECTED]> writes:
> >
> >> But now, when I reinstall dwm-5.2 I get the same problem than in
> >> dwm-5.3 and dwm-5.3.1, "double-fork", "simple-fork" and
> >> re-"double-fork". I don't understand why.
> >
> > This makes me happy, not only because my spawn function wasn't the
> > problem, but also because I can feel again like I know how Unix works :)
> >
> > I now think it is the open file descriptor causing the problem.  The
> > SIGCHLD or double-fork would both cause this behavior; the problem is
> > that the shell running .xinitrc is waiting for an EOF on the pipe it
> > created for STD(IN|OUT|ERR), and is never getting it because you still
> > have some X clients with it open.
> 
> Afair running exec dwmstatus in .xinitrc should delegate this issue to
> dwmstatus, because the problem of running some loop | dwm in .xinitrc
> existed since the very first dwm version and there is no real solution
> to this problem unless the feed process is replaced by something more
> appropriate which uses a fifo redirection.
> 
> > I advise against closing STDOUT or STDERR in the spawn function: that's
> > how error messages make it in to .xsession-errors.
> 
> So far it was only about closing stdin.
> 
> I don't like the alternatives very much, I dislike popen() some status
> feed process, or creating a fifo, or reading from some status text
> file, or using X properties (like larsremote). Reading from stdin in
> dwm is the simpliest and most elegant solution imho.

Amen to that, please keep it the way it currently is. Communication
should be done over stdin/stdout.

Cheers,
Marc

-- 
 Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0

Reply via email to