It seems that there is a way to get an interactive message to the terminal
in batch mode ...

    During daemon startup (with an existing .emacs.desktop file), I get
this on my terminal:

        bunzip2ing contrib-protobufs-2021-06-07-15-56.tbz2...
        bunzip2ing contrib-protobufs-2021-06-07-15-56.tbz2...done
        Parsing tar file...
        Parsing tar file...done
        Please type y, n, ! or i, or C-v/M-v to scroll:

This seems to be from make-progress-reporter, which (if I read the code
correctly) ends up calling (message "%s %s %s" text pulse-char suffix)).
And that message displays interactively on the terminal.

So, there is a way to have the messages from emacsclient --eval display on
the terminal, but in some (most?) situations they don't. (The definition
for message says: "In batch mode, the message is printed to the standard
error stream, followed by a newline.") So, I infer that yes-or-no-p should
just use "message" and all will be fine. (Another example of a prompt that
should go to the terminal but doesn't: "Active processes exist; kill them
and exit anyway" should use "message".)

As to your suggested feature request: I'm not requesting termination of the
server non-interactively - I'm just saying that when the shutdown command
comes from the command line, the messages be output to the terminal, the
way "message" does and not the way yes-or-no-p does.

On Tue, 24 May 2022 at 04:31, Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 55599@debbugs.gnu.org
> > From: Peter Ludemann <peter.ludemann@gmail.com>
> > Date: Tue, 24 May 2022 02:29:37 -0700
> >
> > I don't want to unconditionally save buffers; I want to conditionally
> save them. (Actually, I wouldn't mind if it
> > didn't save the buffers at all; when I restart emacs, it finds the ".#"
> files, and that suffices.)
> >
> > There's a more general problem here (although you might decide it's too
> much trouble to fix) -- it seems that
> > when "emacsclient -e" is used, any prompts go to the non-existent screen
> rather than to the terminal. (e.g.,
> > yes-or-n-p's prompt).
>
> "emacsclient -e" is not meant to support execution of interactive Lisp
> programs, especially not when there's no client frame through which to
> interact with the user.  If you want interaction via emacsclient,
> start emacsclient normally, and then invoke those interactive Lisp
> programs in the client frame that the server opens.
>
> I see no bugs in the behavior you report, and no change from previous
> Emacs versions.  So I'm unsure what issues are being discussed here
> (but see below).
>
> > Also, save-buffers-kill-emacs does two things: (conditionally) saves the
> buffers and deletes the
> > ~/.emacs.d/.emacs.desktop.lock file. On the other hand, the lower level
> kill-emacs doesn't delete the lock file
> > (and the response to bug 55560 is that that's a deliberate design
> decision). So, there's no way of doing from
> > the command line "kill-emacs-and-remove-lock-file", it seems.
>
> You can do anything from the command line, as long as you make sure
> the Lisp program you invoke via the -e switch doesn't ask any
> questions.  E.g., you can invoke a Lisp program that deletes the
> desktop lock file in a kill-emacs-hook, provided that you write such a
> hook yourself and set it in the same Lisp program you pass via -e.
>
> The change that triggered this bug report supports "normal" use of
> emacsclient, whereby the server session is terminated interactively.
> If you insist on doing that noninteractively, you will have to write
> your own Lisp program to do that.  Alternatively, feel free to request
> a new feature of emacsclient whereby you could terminate the server
> session non-interactively via some new command-line option; then the
> implementation of such a feature will have to do all that internally.
>