Re: Problems with lposix on win32

[D Burgess <dburgess@...>]

Hi Rici, Wim,

I consider myself a bit of a "CreateProcess" expert. There are lots
of issues here and exec/spawn probably deserves a thread of
its own.

1) I would suggest that posix spawn() be used rather fork()/exec().
posix_spawn() is avalable under linux and some others. Th spawn()
behaviour is implementable under win32.

2) ShellExecute (and relatives) vs CreateProcess. As you point out
they are very different beasts. I have implemented different Lua
functions for both of these. I believe that ShellExecute does not
have a *nix equivalent.

3) The fun starts when one allows the remapping of stdin/stderr/stdout.
I have done this (without threads) using named pipes and overlapped
io. It works ok.

4) Both the A and W versions of CreateProcess modify the command
string. Note that this "feature" is also a security hole.
"c:\program files param1"
Windows parses the string so that it attempts to execute c:\program.
It may expand or reduce the length of the command string.


DB

On 1/15/06, Rici Lake <lua@ricilake.net> wrote:
>
> On 14-Jan-06, at 1:34 PM, Wim Couwenberg wrote:
>
> >>  You can use ShellExecute.
> >
> > ShellExecute (and CreateProcess) create a *new* process (if file is an
> > executable that is.)  The posix exec family replaces the executable
> > image of the running process.  Very different models...
>
>
> Also, the command parsing model is different. With exec(), you specify
> the argv array directly, so there is less need to worry about
> metacharacters (it is still possible that the utility will misinterpret
> an argument starting with a '-', though.) With ShellExecute and
> CreateProcess, you provide an unparsed command line, which is much
> riskier if you're constructing it from user input.
>
> (In checking the MSDN Library, I also discovered this interesting
> tidbit:
>
>    The Unicode version of this function, CreateProcessW,
>    can modify the contents of this string. Therefore, this
>    parameter cannot be a pointer to read-only memory (such
>    as a const variable or a literal string) or the function
>    could cause an access violation.
>
> Or, in the case of a Lua binding, modify a Lua string with potentially
> disastrous consequences.
>
> Leaving all that aside, though, wouldn't it be possible to implement a
> higher-level interface which did fork+exec on Unix and CreateProcess on
> Windows? That's a fairly commmon situation, anyway. CreateProcess seems
> to be able to specify stdin/stdout/stderr for the newly created
> process, which is what would normally done in the gap between the
> fork() and the exec() in Unix, so there is some hope for an interface
> which would work on both. Although I'm not sure how I would handle
> quoting of "shell" metacharacters.
>