GNU bug report logs - #34123
A patch to fix reading EOF characters in non-interactive mode

Previous Next

Full log

Message #11 received at 34123 <at> debbugs.gnu.org (full text, mbox):

From: Shawn Presser <shawnpresser <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34123 <at> debbugs.gnu.org
Subject: Re: bug#34123: A patch to fix reading EOF characters in
 non-interactive mode
Date: Fri, 18 Jan 2019 08:22:31 -0600

[Message part 1 (text/plain, inline)]

I use Emacs Lisp as a runtime for Arc (https://github.com/shawwn/arcmacs) and
for Lumen (https://github.com/shawwn/y). The goal is to be able to run a
Lisp REPL from the terminal.

For example, in Arc:

  $ git clone https://github.com/laarc/laarc
  $ cd laarc
  $ make
  $ bin/arc
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> 1
  1
  arc> (def my-repl ()
         (pr "> ")
         (whilet expr (read)
           (write (eval expr))
           (prn) (pr "> ")))
  *** redefining repl
  #<procedure: repl>
  arc> (my-repl)
  > 1 ; we can exit this inner REPL with control-D, without exiting the
program.
  1
  > (+ 1 2)
  3
  > ^D
  arc> "If this were emacs in batch mode, the program would have exited
with errors here."
  "If this were emacs in batch mode, the program would have exited with
errors here."
  arc> "Instead, control-D returned us to the toplevel REPL. Let's type
another control-D to quit."
  "Instead, control-D returned us to the toplevel REPL. Let's type another
control-D to quit."
  arc> ^D
  $

Please compare this with arcmacs, which runs in Emacs Lisp:

  $ git clone https://github.com/shawwn/arcmacs
  $ cd arcmacs
  $ ./y-arc
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> 1
  1
  arc> (def my-repl ()
         (pr "> ")
         (whilet expr (read)
           (write (eval expr))
           (prn) (pr "> ")))
  arc> (my-repl)
  > 1  ; if we enter control-D, every REPL exits immediately and the
program quits
  1
  > 2
  2
  > ^D
  arc>
  $ echo We didn't intend to quit yet!

A single ^D exits the entire program, not just the inner REPL. This is
because after the user enters control-D, any attempt to call
`read-from-minibuffer` will always result in emacs throwing an error
with the message "Error reading from stdin".

The only way to gracefully handle this case in a script is to trap the
internal emacs error with (ignore-errors (read-from-minibuffer ""))
and to treat a nil result as if it were EOF. But that causes every
nested REPL to exit, since every attempt to (read-from-minibuffer "")
will throw "Error reading from stdin". In other words, emacs is
always failing to read from stdin after the user sends an EOF.

This patch fixes the problem by causing (read-from-minibuffer "") to
return nil if the user types control-D.


On Fri, Jan 18, 2019 at 7:25 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Shawn Presser <shawnpresser <at> gmail.com>
> > Date: Fri, 18 Jan 2019 04:35:34 -0600
> >
> > $ git clone https://github.com/shawwn/y
> > $ cd y
> > $ bin/y
> > > (read t)
> > Lisp expression: 42
> > 42
> > > (read t)
> > Lisp expression: ^Derror: Error reading from stdin
> > > Error reading from stdin
> > $
> >
> > Notice that it’s currently impossible for non-interactive scripts to
> recover from EOF when reading from tty.
>
> What would you want such non-interactive scripts to do after recovery?
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.