Re: popen problem with command line interpreter

[WU Jun <quark@...>]

On 02/27/2010 08:34 PM, Luiz Henrique de Figueiredo wrote:
> > It appears that the command line Lua interpreter does not trap SIGPIPE:
> >      
> It does not. lua.c is mostly an ANSI C program. It'd have to be a POSIX
> program to trap SIGPIPE.
>    
Then how pcall() be implemented ?
> > rjek@trite:~$ lua
> > Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> >      
> > > f = assert(io.popen("true", "w"))
> > > f:write "Hello, world."
> > > f:close()
> > >        
> > rjek@trite:~$ echo $?
> > 141
> >      
> I get this in Linux:
>    
> > f = assert(io.popen("true", "w"))
> > =f:write "Hello, world."
> >      
> true
>    
> > =f:close()
> >      
> Broken pipe
> (program exits
> > I'm not sure how the situation could be improved much.
> >      
> I don't think it can be improved at all if f:write returns true. Of course,
> f:write probably just buffers the output because if I replace f:close with
> f:flush I get the same error (Broken pipe).
>
>    
Exactly same broken pipe can be verified using C:

#include <stdio.h>
#include <unistd.h>

int main(int argc, char const* argv[])
{
    FILE * f = popen("true", "w");
    usleep(1 << 18); // sleep sometime, pipe should be invalid.
    fprintf(f, "hello world");
    pclose(f); // cause exit, code 141
    return 0;
}

Since POPEN manual page says "output popen() streams are fully buffered 
by default."
I think f:write return true is resonable.


I am wondering why pcall(function() f:write('bla') f:flush() end) is not 
safe? Because it didn't trap  SIGPIPE? Is it the same question?