Works for me. I was about to patch my tree like that.
On 6/20/05, felix winkelmann <[EMAIL PROTECTED]> wrote:
> To be honest, I can't think of anything better than returning the status code
> in the moment.
___
Chicken-users mailing list
Chicken-users
Oh---for those without the chicken manual at their fingertips---in
(with-input-from-pipe COMMAND THUNK) the error code from COMMAND is
not available until after THUNK finishes and the pipe is closed. And
with-input-from-pipe just returns the results of THUNK. That is why
returning an error code w
On 6/20/05, Zbigniew <[EMAIL PROTECTED]> wrote:
> Oh---for those without the chicken manual at their fingertips---in
> (with-input-from-pipe COMMAND THUNK) the error code from COMMAND is
> not available until after THUNK finishes and the pipe is closed. And
> with-input-from-pipe just returns the
Am Montag, den 20.06.2005, 11:51 -0500 schrieb Zbigniew:
> close-input-pipe discards the return value of the process you invoked,
> so you can't figure out if it failed. It only signals an error (via
> exception) if the system call failed.
>
> In Perl, close(pipe) will fail on a non-zero exit cod
On 6/20/05, Jörg F. Wittenberger <[EMAIL PROTECTED]> wrote:
> Am Montag, den 20.06.2005, 11:51 -0500 schrieb Zbigniew:
> > An easy fix is to have close-input-pipe return the value from pclose()
> > (stored in the variable "r"), since it currently returns nothing at
> > all. Semantically it makes
close-input-pipe discards the return value of the process you invoked,
so you can't figure out if it failed. It only signals an error (via
exception) if the system call failed.
In Perl, close(pipe) will fail on a non-zero exit code (though the
code is returned out of band, in $?).
An easy fix is
