Reuben Thomas wrote:
liolib.c was written as a self-contained Lua extension---it has no global symbols except luaopen_io. This is good practice, if there are no other considerations. I'm arguing here that exposing a small part of the internals would significantly help other extensions. While I'm asking for things, it might be nice to have either or both of the existingHey, Lua maintainers: this could be a fix for it: liolib.c: int luaIO_filecreate(lua_State *L, FILE *f) { FILE **pf = newfile(L); *pf = f; return 1; }That's a good idea, and its lack a bit puzzling in retrospect: "what, no simple constructor?".
static FILE **topfile (lua_State *L, int findex) and static FILE *tofile (lua_State *L, int findex)exposed to the outside; these functions allow other extensions to pull the FILE* out of a filehandle userdata. I don't have a compelling reason off the top of my head, but it feels like somebody might need to run something like fileno() on an existing handle, perhaps as an argument to select().
Yeah. The notional popen2.lua would fork and execve the child process attached through file descriptors. The posix module then implements posix.fdopen(fd, mode) in terms of luaIO_filecreate, and then returns a filehandle userdata to the caller.Would that stop you needing to use the shell?
Jay