On 07/15/14 23:55, Philip Guenther wrote:
On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell <gus...@nyvell.se <mailto:gus...@nyvell.se>> wrote:

    On 07/15/14 11:13, Peter Hessler wrote:

        On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav
        Fransson Nyvell wrote:
        :On 07/15/14 09:48, Philip Guenther wrote:
        :>When the process that's executing your .xinitrc exits,
        startx/xinit
        :>will shutdown the X server and then itself exit, taking you
        back to
        :>the non-X shell prompt.  Your .xinitrc should end with
        execution on
        :>some program which will not exit until you want to exit X; many
        :>people have it be their window manager.
        :>
        :>This is described in the startx(1) manpage:
        :>       The .xinitrc is typically a shell script which starts
        many clients
        :>       according to the user's preference.  When this shell
        script exits,
        :>       startx kills the server and performs any other session
        :>shutdown needed.
        :>       Most of the clients started by .xinitrc should be run
        in the
        :>       background.  The last client should run in the
        foreground; when it
        :>       exits, the session will exit.  People often choose a
        session
        :>manager,
        :>       window manager, or xterm as the ''magic'' client.
        :>
        :I know all of this. The problem is why does X lose .xinitrc when
        :.xinitrc (ksh) forks.
        :

        because the process you called stopped running.

    It does not. If you mean daemon() I run it from inside a fork() so
    the main process never exits. You're making me uncertain so I will
    check this out better later.


So you're saying that the process that the .xinitrc ksh executes calls fork() and the child of that fork() then calls daemon()? If so, what does the *parent* of the fork(), the original process executed by ksh, do after forking? It's child will exit from the daemon() call, so if it calls wait() it won't block long. Then what? Exit? If so, you've created a self-backgrounding process (in a very complicated fashion) which means it cannot be the process that keeps the .xinitrc script from exiting.
Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this.


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.


    This e-mail is confidential and may not be shared with anyone
    other than recipient(s) without written permission from sender.


You should ask your legal department what they think that means other than "we're idiots" when attached to messages to archived mailing lists.
The legal department knows what a mailing list is. Mails are sent out to consumers, those are the (final) recipients.


Philip Guenther



--
This e-mail is confidential and may not be shared with anyone other than 
recipient(s) without written permission from sender.

Reply via email to