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

[Ludovic Courtès]

Hi,

Fredrik Salomonsson <plattfot@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.

HTH,
Ludo’.