On 5/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
While I'm working on a solution to permit cmd.exe to be launched from
a service process within Win32, I'm still struck by the inefficiency
here and feel we need to resolve the core issue.

Regarding the inefficiency, it doesn't seem to be a big deal.  It
takes a trivial amount longer to start up the piped logger, and a
process hangs around consuming a trivial amount of resources.

I think it is more an issue of neatness -- does somebody want to see
that process hanging around.

Apparently it is a good APR testcase as well ;)

So I brought up to the list 'fixing' this with an additional meta
character to follow | that would distinguish sh from non-sh invocations,
and permit both.  Since we really need to fix this in 2.2 / 2.0 and want
to do so harming as few users as possible (it would be clearly called
out in CHANGES, but none the less) please vote between one of these
two possible solutions that could be applied to 2.0 and 2.2 branches...

 [ ] Revert to "|foo" to invoke foo, and
     add "|$foo" syntax to launch foo via sh

 [ ] Retain "|foo" to invoke foo through sh, and
     add "||foo" syntax to directly launch foo

Just to be weird:

|$foo syntax launches foo via sh
||foo syntax launches foo directly

|foo tries to make the right decision:

Windows:
APR is busted, so launch foo directly

Other platforms:

starts with slash and contains no redirection?
 launches foo directly
else
 launches foo via sh

This is expected to do the right thing for just about everybody --
almost no regression, with neatness improvement (Unix users not
needing to see the extra /bin/sh hanging around) or functional
improvement (Windows users avoiding APR problem) for most folks.

Drawback: Some people may not be ready to understand the resulting doc.

Reply via email to