GNU bug report logs - #44642
27.1; read-string does not signal on EOF after calling server-eval-at

Previous Next

Full log

View this message in rfc822 format

From: Chris Hunt <chrahunt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44642 <at> debbugs.gnu.org
Subject: bug#44642: 27.1; read-string does not signal on EOF after calling server-eval-at
Date: Sat, 14 Nov 2020 15:40:31 -0500

> In that case, I see no bug here.   read_minibuf_noninteractive calls
> 'getchar'; if that is interrupted by a signal, we retry the call; thus
> the infinite loop.  In your case, I'm guessing that the signal is
> SIGPIPE, because the input of the Emacs process is from a pipe, and
> the other side of the pipe exited.

Thanks, that seems like a reasonable guess. I don't know how to
confirm the specific signal causing the EINTR.

If not a bug, I think there is at least some room for improvement. The
stated behavior of
`read-string' (via `read-from-minibuffer') is:

  If default is nil, empty input results in an end-of-file error.

I was relying on this for an input loop of the form.

#+begin_src emacs-lisp
(while (setq command (ignore-errors (read-string "")))
  (setq command (read command))
  (message "[DEBUG] Received command %s" command)
  (let ((result (eval command)))
    (message "[DEBUG] Response received %s" result)))
#+end_src

Which works fine until using `(server-eval-at (getenv
"RPC_SERVER_NAME") command)` in place
of `(eval command)` - that's when the unexpected behavior is observed.
Something in the docs for `read-string', `--batch', `server-eval-at',
or the list of known issues
could be a start - "if using `server-eval-at' in `--batch' mode, take care not
to possibly read to the end of input"

> If my analysis is correct, then your script setup needs to be modified
> to not trigger this condition.

For my use case I think I can work around this using a sentinel value,
killing the process explicitly from the parent, or switching to an
approach using jsonrpc.el.

Previous Next

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