GNU bug report logs - #55420
[PATCH 0/2] Add a function to parse emacs elisp's package header

Previous Next

Full log

View this message in rfc822 format

From: Fredrik Salomonsson <plattfot <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 55420 <at> debbugs.gnu.org
Subject: [bug#55420] [PATCH 0/2] Add a function to parse emacs elisp's package header
Date: Sun, 05 Jun 2022 00:42:34 +0000

Hi Ludo,

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

> Hi,
>
> Fredrik Salomonsson <plattfot <at> posteo.net> skribis:
>
>> Here is what I have so far:
>>
>>     (define-condition-type &emacs-batch-error &error
>>       emacs-batch-error?
>>       (expression emacs-batch-error-expression)
>>       (message emacs-batch-error-message))
>>     
>>     (define (emacs-batch-script expr)
>>       "Execute the Elisp code EXPR in Emacs batch mode and return output."
>>       (let* ((error-pipe (open-output-string))
>>              (pipe (with-error-to-port error-pipe
>>                      (lambda ()
>>                        (open-pipe*
>>                         OPEN_READ
>>                         (%emacs) "--quick" "--batch"
>>                         (string-append "--eval=" (expr->string expr))))))
>>              (output (read-string pipe))
>>              (error (get-output-string error-pipe))
>>              (status (close-pipe pipe)))
>>         (unless (zero? status)
>>           (raise (condition (&emacs-batch-error
>>                              (expression expr)
>>                              (message error)))))
>>         output))
>
> Unfortunately ‘open-pipe*’ is not smart enough to redirect stderr to a
> non-file port (a string port in this case).
>
> One way around it would be to merge stdout and stderr, like so:
>
>   (parameterize ((current-error-port (current-output-port)))
>     (open-pipe* …))
>
> but then you get both on the same stream, which could be a problem for
> instance if Emacs emits warnings and such.
>
> You could work around it by establishing a second pipe:
>
>   (match (pipe)
>     ((stderr-input . stderr-output)
>      (parameterize ((current-error-port stderr-output))
>        (open-pipe* …))))
>
> Here you should be able to read, in the parent process, from
> ‘stderr-input’.
>
> Another option is to not try to capture stderr: after all, that’ll get
> printed on the screen anyway.

I just sent in v2 of the patches. Changes are:

- emacs-batch-script will now raise an &emacs-batch-error if emacs batch
  script fails. I opted to capture the stderr and package that up in the
  condition. Thank you for the pointers! I removed the expression slot I
  had in my prototype. It felt redundant, emacs error message should be
  enough.

- tests/build-emacs-utils.scm: I added tests for the two new procedures.

It was good that I added the tests as I had missed to use (srfi srfi-34)
in build/emacs-utils.scm during my prototyping and that generated the
cryptic error:

   Wrong type (expecting exact integer): #<&emacs-batch-error…>

Took me a while to figure that one out. But now all is good. The tests
are passing.

Thanks again.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.