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