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

[Chris Hunt]

> 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.