Specifically, add posix_spawn() and friends, and also pipe() and close()
wrappers. Note that posix_spawn() is not in luaposix.
The posix_spawn() interface tries to be flexible. All parameters except
the executable name/path and process arguments are optional. For
example, one can write:
posix_spawn("/bin/ls", {"ls", "-l"})
or
posix_spawnp("env", {"env"}, {"FOO=BAR"})
The file_actions interface is a bit more involved, but can be used to do
things like pipe output of one process to another, or collect standard
output in a string. We are missing a few things to make useful
examples, but it's relatively straightforward.
I would like to replace the "fbsd" module, which provides a much more
limited wrapper for posix_spawn(). In general, I prefer to wrap C
functions directly, and then provide helper functions written in Lua.
The posix_spawn() interface above is clunky, but with that it's easy to
add functions which exec a process and variously:
- pipe output to another process
- wait for the proc to exit and return output as a string
- print the current stdin/stdout/stderr
- ...
The other "interesting" thing is the use of a userdata type to represent
file descriptors. I provided pipe() and close() implementations to
demonstrate this. They are not too useful on their own, but they help
demonstrate how to
I don't really consider this to be committable yet, just a starting
point for some discussion. One consideration is how we should split up
the sources; cramming everything into one file doesn't seem to be
scalable. The obvious approach would be to have modules/posix/spawn.c,
modules/posix/unistd.c, etc..
One other consideration is how to handle userdata types like the one
used for file descriptors. Should this be part of the core flua
implementation? Ideally it could be used across different modules
(e.g., with a hypothetical freebsd.sys.capsicum.cap_rights_limit()), so
does not really belong in the posix module.