bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Shawn Presser
Subject: bug#34123: A patch to fix reading EOF characters in non-interactive mode
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 <address@hidden> wrote:
> From: Shawn Presser <address@hidden>
> Date: Fri, 18 Jan 2019 10:20:54 -0600
> Cc: address@hidden
>
> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]