Subject: bug#34123: A patch to fix reading EOF characters in non-interactive mode

From: Shawn Presser <[email-masked]>
Date: Fri, 18 Jan 2019 11:23:11 -0600

> What I mean by noninteractive is when stdin is not connected to a
terminal.  Your proposed patch affects that case as well, doesn't it?

I don't think so, because the only case that this patch affects is the case
where emacs would signal "error reading from stdin". I don't think I've
ever seen emacs throw that error during normal emacs usage, even when
reading from stdin not connected to a terminal.

But admittedly, I am not certain in all cases. It's probably better to
phrase this as a question: Has any elisp code been written to handle "error
reading from stdin"? For example, (ignore-error ...) would mask the error
message, if it could somehow be generated during normal emacs operation.

However, even in that case, the operation of emacs would end up exactly the
same, since `nil` is now returned, which is exactly what the `(ignore-error
...)` expression would return (if such code already exists).

That said, it would be surprising if this were expected behavior, because
the only way for user code to detect and handle it would be to parse the
error message, since it's a regular 'error type rather than a type that can
be handled via condition-case. I don't think this situation has been
covered till now, because emacs users typically don't care about reading
from stdin in batch mode.

Actually, I just found a blog post from 2014 that complains about this very
case:
http://joelmccracken.github.io/entries/reading-writing-data-in-emacs-batch-via-stdin-stdout/

> When EOF is read, an error is thrown, which is useless to us. Instead of
worrying about the error, we can wrap the function call in an ignore-errors
macro, which will return nil when an EOF occurs.

They don't seem to care about being able to call read-from-minibuffer
multiple times. But if they did care, they would find it quite impossible
after the first EOF.

On Fri, Jan 18, 2019 at 10:29 AM Eli Zaretskii <[email-masked]> wrote:

> > From: Shawn Presser <[email-masked]>
> > Date: Fri, 18 Jan 2019 10:20:54 -0600
> > Cc: [email-masked]
> >
> > It's non-interactive:
> >
> > arc> |noninteractive|
> > t
> >
> > (The expression |noninteractive| in arcmacs is equivalent to evaluating
> 'noninteractive in emacs lisp.)
> >
> > The runtimes start by invoking emacs using `emacs -Q --script ...`, so
> it's always noninteractive. And in
> > general for writing shell scripts rather than repls, it's important to
> be in noninteractive mode. But it's equally
> > important to have the ability to prompt the user from a shell script,
> and for the user to be able to cancel by
> > using ^D without causing stdin errors on all subsequent prompts.
>
> I think we are miscommunicating, since your usage involves Emacs
> reading from the terminal.  That is not noninteractive in my book.
> What I mean by noninteractive is when stdin is not connected to a
> terminal.  Your proposed patch affects that case as well, doesn't it?
>