Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!sdd.hp.com!mips!pacbell.com!pacbell!sactoh0!csusac!unify!openlook!openlook-request From: Stuart.Marks@Eng.Sun.COM (Stuart Marks) Newsgroups: comp.windows.open-look Subject: Re: Help with SunSO OpenWindows 2.0 window manager and Saber C Message-ID: Date: 8 May 91 23:46:05 GMT Lines: 44 I have the following as one line of many within my $HOME/.openwin-menu file: "Saber-C" xsaber & I have tried just xsaber, exec xsaber, and the above. In each case, I see the outline of the primary window, but before any text appears, the windows go away. I'm not totally sure what's going wrong, but I believe this problem occurs because olwm puts its child processes into a different process group before exec'ing the program. Olwm does *not* divorce the program from its controlling terminal, though. This is a rather odd situation, and perhaps this is the cause of saber's trouble. I do have a workaround, however. Try running saber with its stdin redirected from the console, e.g. "Saber-C" xsaber < /dev/console This seems to make the problem go away. From looking at trace output, it appears that saber is doing an ioctl(0, TCGETA), which is failing with EINVAL. (1) I'm not sure why it's failing. (2) I don't know why saber exits when this fails. This is easy to reproduce by closing stdin before running saber, e.g. "saber <&-" in sh/ksh. Saber appears to exit silently (with exit code 0!) when this happens. Perhaps someone from Saber can respond to this off-line. How can one start programs so that stderr type messages appear SOMEWHERE? And of course, how do we find that somewhere :-) . Programs exec'ed from olwm inherit olwm's stdin, stdout, and stderr. Olwm is typically started from the console, along with the rest of the system, so stderr messages will go to the console terminal. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Windows & Graphics Software UUCP: sun!smarks Sun Microsystems, Inc.