[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: capture stdout and stderr
From: |
Catonano |
Subject: |
Re: capture stdout and stderr |
Date: |
Tue, 29 May 2018 19:35:27 +0200 |
2018-05-27 19:26 GMT+02:00 Thomas Danckaert <address@hidden>:
> From: Stefan Israelsson Tampe <address@hidden>
> Subject: Re: capture stdout and stderr
> Date: Thu, 24 May 2018 15:25:51 +0200
>
> I think that your code whould work but doesn't because string ports are
>> not file ports and system commands pipes out to file ports.
>>
>> 'open-input-pipe' uses 'scm_open_process' that returns only a read-port
>> and a write-port, the write port is then taped the output string in your
>> run-command.
>> and it works.
>>
>> ALso when you create a err-port with pipe, you create a file port nad
>> this will be used translated as an error port for the system comand and it
>> all works.
>> However the failing program uses a string port which is not a file port
>> and it does not end up capturing the error output in the system command.
>>
>> One would wish that guile if the error port is not a file port make a
>> file port, as done with 'pipe' and create a thread that pipes the data from
>> the file port to the non file port and your code
>> would work. Also similarly behavior for read and write ports towards the
>> shell.
>>
>> the relevant code is in posix.c, scm_open_process
>>
>
> Hi! Thanks for the message. Indeed, that makes sense. In fact I had some
> vague intuition that some magic would be needed to channel the stderr
> output into such a string port. I think the manual could be more explicit
> about that, though? (e.g. in the section on default ports
> https://www.gnu.org/software/guile/manual/html_node/Default-
> Ports.html#Default-Ports ). Maybe I should propose a patch to the docs,
> stating that those "with-x-to-port" methods only work on file ports.
>
> Thomas
>
>
>
Thomas
thank you for sharing the solution