Re: os.execute is scary; Jay rants about strings again (was Re: [ANNOUNCE] lua stdlibs release: now Lua 5 compatible)

[Jay Carlson <nop@...>]

Reuben Thomas wrote:

> > Hey, 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?".

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 existing

  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().

> Would that stop you needing to use the shell?

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.

Jay