[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Problems with lposix on win32
- From: Chris Marrin <chris@<a href="/cgi-bin/echo.cgi?marrin.com">...</a>>
- Date: Sat, 14 Jan 2006 21:00:59 -0800
D Burgess wrote:
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
Ok, I have looked at the descriptions of execvp() in win32 docs and the
Posix spec. Win32 says it creates a "child process" while Posix says it
"replaces the currently running process". I have trouble understanding
this. Does the calling process exit cleanly, or just cease to exist?
I thought both did the same thing, meaning that I always thought the
Unix version did not gun down the calling process. I guess I have been
using Windows for too long, which is sad.
Anyway, generally, I think the goal of this "osex" package should not be
to throw in the kitchen sink. This is why I felt that fork() should be
left out. Nice, (albeit old fashioned), but its arcane process semantics
has little chance of running on smaller systems. The same is true of
spawn(), kill() and many of the other process control functions.
I would like it to contain a small number of useful file-system and
environment calls. So I think the current list:
"access", "chdir", "chmod", "errno", "exec", "getcwd",
"getenv", "mkdir", "putenv", "rmdir", "sleep", "stat",
should lose exec() altogether, and gain dir() and/or files().
On that subject, it seems wasteful to have a forms of directory
discovery which return an array of string names (dir) and an iterator
which will return each string name in turn. It seems like we only really
need files(). How does that sound?
"As a general rule,don't solve puzzles that open portals to Hell"