On Wed, Jul 16, 2014 at 3:45 AM, Gustav Fransson Nyvell <[email protected]> wrote:
> On 07/16/14 10:31, Philip Guenther wrote: > > On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell <[email protected] > > wrote: > >> On 07/15/14 23:55, Philip Guenther wrote: >> > ... > So let's try that question directly: what process (*not* program) >> directly executed in the foreground by the .xinitrc script will run and not >> exit until your X session is complete? The answer CANNOT be "the child of >> this program which fork()s", because it is the original process which >> matters. Nor can the answer be "this program which calls daemon()", >> because the original process exits then too. >> >> Not a process in .xinitrc, .xinitrc itself. >> > > I don't understand your answer. Since I apparently cannot guess what > you're doing, I'll suggest that you show it, such as by simply including > your complete .xinitrc. > > couth. ~$ cat > .xinitrc > urxvtd -o & > xrdb ~/.Xresources > echo $$ > exec wmaker > So the process which is run and that doesn't exit until your X session is complete is the process that started as .xinitrc but then execed wmaker. At that point, there should be no process executing the .xinitrc script at all, as it has execed something else. Since you exec'ed wmaker instead of running it in the foreground, the urxvtd process will be a child process of wmaker. If that's confusing wmaker, then just stop using exec. No, I've patched /usr/src/bin/ksh. I suggest you copy the source and install your modified version under some other name, so that you can be confident that your changes aren't the source of questions you're asking on the lists. We can't support Gustav-ksh. Oh, I see, that's exactly what's happened: you've hacked ksh to call a library that forks and your .xinitrc stopped working as a result. "Doctor, it hurts when I poke myself with a fork()" "So don't do that!" Philip Guenther
