[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ex API
- From: Mark Edgar <medgar@...>
- Date: Mon, 13 Feb 2006 20:08:28 -0700
Chris Marrin wrote:
Sorry I dropped the ball on this a few weeks ago. Thanks for coming up
with a nice strawman.
It's been a lot of fun so far. ;)
I am very confused about spawn, as it relates to exec(). I thought
execvp() (which you used for the Linux implementation) replaced the
currently running process with the given file, as stated here:
os.spawn() creates a new process running the program loaded from the
specified file. It does not replace the current process with another
My "POSIX" implementation of os.spawn() uses posix_spawnp(). I've
included a "stub" implementation of posix_spawnp() written in terms of
fork() and execvp() for those systems (e.g. Cygwin) which don't have
posix_spawnp(). This stub implementation of course creates a new
process, just like posix_spawnp() does.
To be clear: os.spawn(), if successful, always creates (spawns) a new
child process/program, returning a 'proc' userdatum to the Lua program.
Personally, I have little use for exec(). I find pipe() and system() to
do what I need in these areas. They are horrible, but I can get them to
do what I need! I also have never had any need for an explicit file
lock/unlock semantic. Seems like this is the domain of databases and
transaction processing, so they would fit better in a package like that.
But maybe many others see the utility of this.
I don't see how pipe() and system() work together. Maybe you mean
popen(), which is kind of a cross between pipe() and system(), handling
the common cases of writing to a process's stdin, and reading from a
process's stdout. With both io.pipe() and os.spawn(), one could write a
pure Lua implementation of io.popen().
The lock and unlock functions are there because I stole them from
LuaFileSystem. I haven't personally made use of them yet.
I have become partial to Rici's proposal of an environment table with
metamethods to interface it to the system environment. So you would say:
print("user=", os.environ["USER"]) -- for getenv()
os.environ["MY_FAV_COLOR"] = "yellow" -- for setenv()
os.environ["MY_FAV_COLOR"] = nil -- for unsetenv()
I like the magic env table too. I just think that the functions are
more "primitive" than the table interface. Also, having os.setenv and
os.unsetenv makes for a nice parallelism with the core os.getenv.