bug#56218: closed ([PATCH] guix: inferior: Fix the behaviour of open-inferior #:error-port.)

[GNU bug Tracking System]

Your message dated Fri, 08 Jul 2022 13:54:24 +0100
with message-id <87ilo792zl.fsf@cbaines.net>
and subject line Re: bug#56218: [PATCH] guix: inferior: Fix the behaviour of 
open-inferior #:error-port.
has caused the debbugs.gnu.org bug report #56218,
regarding [PATCH] guix: inferior: Fix the behaviour of open-inferior 
#:error-port.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
56218: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56218
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> [PATCH] guix: inferior: Fix the behaviour of open-inferior #:error-port.
>
>
>
>
> Date: 
>
> Sat, 25 Jun 2022 18:18:47 +0100
>
>
>
>
> This should be the error port used by the inferior process, but currently it's
> either stderr if #:error-port is a file port, or /dev/null otherwise.
>
> I'm looking at this as the Guix Data Service uses this behaviour to record and
> display logs from inferior processes.
>
> * guix/inferior.scm (open-bidirectional-pipe): Call dup2 for file descriptor
> 2, passing either the file number for the current error port, or a file
> descriptor for /dev/null.
> ---
>  guix/inferior.scm | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/guix/inferior.scm b/guix/inferior.scm
> index 54200b75e4..e36806ac84 100644
> --- a/guix/inferior.scm
> +++ b/guix/inferior.scm
> @@ -156,12 +156,14 @@ (define (open-bidirectional-pipe command . args)
>              (close-port parent)
>              (close-fdes 0)
>              (close-fdes 1)
> +            (close-fdes 2)
>              (dup2 (fileno child) 0)
>              (dup2 (fileno child) 1)
>              ;; Mimic 'open-pipe*'.
> -            (unless (file-port? (current-error-port))
> -              (close-fdes 2)
> -              (dup2 (open-fdes "/dev/null" O_WRONLY) 2))
> +            (dup2 (if (file-port? (current-error-port))
> +                      (fileno (current-error-port))
> +                      (open-fdes "/dev/null" O_WRONLY))
> +                  2)
>              (apply execlp command command args))
>            (lambda ()
>              (primitive-_exit 127))))
> -- 
> 2.36.1
>
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#56218: [PATCH] guix: inferior: Fix the behaviour of open-inferior #:error-port. Date: Fri, 08 Jul 2022 13:54:24 +0100 User-agent: mu4e 1.6.10; emacs 28.1

Ludovic Courtès <ludo@gnu.org> writes:

>>>> +            (dup2 (if (file-port? (current-error-port))
>>>> +                      (fileno (current-error-port))
>>>> +                      (open-fdes "/dev/null" O_WRONLY))
>>>> +                  2)
>>>
>>> If (current-error-port) wraps FD 2 when the function is called, then, by
>>> the time we reach (dup2 … 2), the FD behind (current-error-port) has be
>>> closed; we end up doing (dup2 2 2), but FD 2 is closed, so we get EBADF.
>>>
>>> Or am I misunderstanding?
>>
>> That sounds reasonable, I've only tested this change in the scenario
>> when the #:error-port isn't stderr, and I mostly adapted this from what
>> I thought open-pipe* did.
>>
>> Maxime suggested using move->fdes, so maybe this would be an improved
>> version:
>>
>>   ;; Mimic 'open-pipe*'.
>>   (if (file-port? (current-error-port))
>>       (unless (eq? (fileno (current-error-port)) 2)
>>         (move-fdes (current-error-port) 2))
>>       (move->fdes (open-file "/dev/null" O_WRONLY) 2))
>
> I prefer the original version: I find it clearer (it’s low-level) and
> probably more robust (thinking through the port/FD interaction needs is
> more demanding :-)).
>
>>> Perhaps we should add one test for each case (error port is a file port
>>> vs. error port is another kind of port) in ‘tests/inferior.scm’.
>>
>> Yep, sounds good.
>
> To sum up: I think it’s a welcome change, and it’s even more welcome
> with a couple of tests to make sure it behaves the way we think it does.

I've gone ahead and pushed a fix plus some tests as
a9fd06121240c78071a398dd1e0ddb47553f3809.

The tests probably aren't great, but I think the do cover the
#:error-port behaviour.

signature.asc
Description: PGP signature

--- End Message ---