Re: PATCH: Lua 5.0.2 popen/pclose fix (was Re: segfault in io.close and a plea for pipes)

[David Burgess <dburgess@...>]

I think I have addressed my popen() problem for win32.
After some iteration, I have a popen() function whose only
requirement is that it is openlib()ed. The rest of the IO
library just works with it (work6). Plus

   - The GUI program restriction of the MS RTL _popen() is removed
   - pclose() is not required, the handle is mapped to a FILE* so it
     closes with fclose() just like any other fp.
   - tested for handle leaks
   - additional mode characters, namely;
       2 - maps stderr to stdout
       s - uses the windows shell (COMSPEC)
       h - hides any child process windows
       n - uses a NULL handle for unspecified child handles.
           Without this option the parent handle is inherited by the child.
           process.
           If the parent stdin, stdout, stderr are not initialized correctly
           (as in the case of a GUI parent) the popen() may fail unless this
           option is provided.

The C module also comes with an exec() function that spawns using
IO completion ports and provides Lua call backs to perform std io for the
child process. 

I can send you this code if you want it.

My presumption is that popen() is generally not an issue for Unix systems
and that some kind soul will provide the perfect popen() implementation
for work6.

Finally,  the recent posts of LuaFileSystem and CGILua. There the 
approach seems to be to replace the IO library completely (albeit cloning
the existing code). While I like the work6 IO lib code implementation,
methinks there must be a better way to offer extensibilty than cloning the
code each time.

David Burgess

On 6/1/05, L. H. de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> > But since lhf suggested the removal from the standard library,
> > there is some hope that he adds it to his POSIX library. ;-)
> 
> Yes, it's in the TODO list for lposix.
> 
> > Unfortunately this requires a large amount of code duplication
> > from liolib.c. The methods are not inheritable because of the
> > strict metatable checks (and you really need to override close()).
> 
> liolib could probably be made generic. There has been some talk about this
> on the list, but no code, AFAIK.
> 


-- 
David Burgess