Return-Path: 
 <dev-return-8498-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 7339 invoked by uid 500); 22 Nov 2002 21:19:25 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 7228 invoked from network); 22 Nov 2002 21:19:23 -0000
Message-Id: <5.1.0.14.2.20021122144157.02b3bd88@pop3.rowe-clan.net>
X-Sender: admin%rowe-clan.net@pop3.rowe-clan.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 22 Nov 2002 15:14:43 -0600
To: "Ich Selbst" <ichselbst@gmx.ch>
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: apr_proc_create
Cc: <dev@apr.apache.org>
In-Reply-To: <007b01c290c8$c6a58370$3140d0c2@catv64254>
References: <5.1.0.14.2.20021120125603.041ae2e8@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 22 Nov 2002 21:19:27.0442 (UTC)
 FILETIME=[D69B4B20:01C2926C]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

At 01:12 PM 11/20/2002, Ich Selbst wrote:
>> IIRC... if you do this, you lose stdin/out/err, which are set up
>> by the cmd engine.  I believe this is the reason that flag wasn't
>> used.
>
>No. If the app uses stdin and normal out, then the flag will have
>no effect (according to the docs). And if you want to start
>an app invisible then you don't need stdin/out/err anyway.

Most applications we've envisioned APR used do communicate
with the parent process through stdin/out/err.  Some alternate
method needs to be created for WinCE (which has no std handles)
but at this moment, changing this would break many APR users.

>I'd rather loose stdin/out/err if I want to start an app invisible
>(the app won't crash, those streams are just redirected to the void).
>Right now every app which is started invisible will still pop
>up the console window which is very disturbing (try merge
>command with subversion -> subversion then calls the diff
>commands to do the job and the console is shown).

Well, we know if standard handles were set up for the child
process.  If they are all absent (NULL), I don't see a problem with 
setting this flag.

Let me spend a little time tommorow considering a patch before
I apply any fix.  Thanks.

>If you need the console then the app should be started with
>other flags - or started not directly but with "cmd /c <appname>".

Huh?  Definately not.  The *standard* use case for creating any
processes is that the parent process needs to communicate with
the newly created process.  There is *no* reason to add the extra 
footprint of invoking a shell, when the image to launch is executable.

>btw: what does IIRC mean?

If I Recall Correctly...