Really noninteractive

Really noninteractive

[Lars Ingebrigtsen]

I somehow expected

(let ((noninteractive t)) (read-string "foo: "))

to error out, since the documentation of the variable is:

---
Non-nil means Emacs is running without interactive terminal.
---

I'm trying to use Emacs from a server context, and would prefer that
Emacs signal an error whenever you tell it to do something interactive
rather than hang forever.

Is there a way to do this that I've missed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Really noninteractive

[Andreas Schwab]

On Feb 20 2020, Lars Ingebrigtsen wrote:

> I'm trying to use Emacs from a server context, and would prefer that
> Emacs signal an error whenever you tell it to do something interactive
> rather than hang forever.

Run emacs in batch mode.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Really noninteractive

[Ihor Radchenko]

> Is there a way to do this that I've missed?

The Elisp manual says:

 -- Variable: noninteractive
     This variable is non-‘nil’ when Emacs is running in batch mode.

So, in your case, emacs does not really hang, but awaits input from
terminal. You can test it by running emacs in batch mode (as suggested
by Andreas):

emacs -Q --batch --eval "(let ((noninteractive t)) (read-string \"foo: \"))"

Probably, docstring needs to be clarified to conform with the manual.

Best,
Ihor


Lars Ingebrigtsen <larsi@gnus.org> writes:

> I somehow expected
>
> (let ((noninteractive t)) (read-string "foo: "))
>
> to error out, since the documentation of the variable is:
>
> ---
> Non-nil means Emacs is running without interactive terminal.
> ---
>
> I'm trying to use Emacs from a server context, and would prefer that
> Emacs signal an error whenever you tell it to do something interactive
> rather than hang forever.
>
> Is there a way to do this that I've missed?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: Really noninteractive

[Lars Ingebrigtsen]

Andreas Schwab <schwab@suse.de> writes:

>> I'm trying to use Emacs from a server context, and would prefer that
>> Emacs signal an error whenever you tell it to do something interactive
>> rather than hang forever.
>
> Run emacs in batch mode.

I don't want to do that -- I just want to ensure that certain code paths
aren't interactive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Really noninteractive

[Lars Ingebrigtsen]

Ihor Radchenko <yantar92@gmail.com> writes:

> The Elisp manual says:
>
>  -- Variable: noninteractive
>      This variable is non-‘nil’ when Emacs is running in batch mode.
>
> So, in your case, emacs does not really hang, but awaits input from
> terminal.

I think that's what I said?  And I wondered whether there was any way to
make that error out instead of prompting.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Really noninteractive

[Noam Postavsky]

On Thu, 20 Feb 2020 at 12:43, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> >  -- Variable: noninteractive
> >      This variable is non-‘nil’ when Emacs is running in batch mode.
> >
> > So, in your case, emacs does not really hang, but awaits input from
> > terminal.
>
> I think that's what I said?  And I wondered whether there was any way to
> make that error out instead of prompting.

I think if you redirect stdin from /dev/null any
noninteractive/batch-mode reading will fail immediately.

Re: Really noninteractive

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> I think if you redirect stdin from /dev/null any
> noninteractive/batch-mode reading will fail immediately.

Yes, but that's not what I want.  :-)  I want to say "this function
call, in this otherwise totally normal Emacs, should not prompt".

I.e., what my original example said:

(let ((noninteractive t)) (read-string "foo"))
=> error

But it's starting to sound like nobody's implemented this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Really noninteractive

[Clément Pit-Claudel]

On 2020-02-20 10:23, Andreas Schwab wrote:
> On Feb 20 2020, Lars Ingebrigtsen wrote:
> 
>> I'm trying to use Emacs from a server context, and would prefer that
>> Emacs signal an error whenever you tell it to do something interactive
>> rather than hang forever.
> 
> Run emacs in batch mode.

How does that help?  It still prompts and waits for an answer, AFAICT.

Re: Really noninteractive

[dick.r.chiang]

LI> Yes, but that's not what I want.  :-) I want to say "this function call,
LI> in this otherwise totally normal Emacs, should not prompt".

Okay, so you've established that `noninteractive` only diverts "normal emacs"
to call `read_minibuf_noninteractive()` which in turn attempts to get input
from stdin, which as we all know by now, *you do not want*.

It's not clear what else you expect from us apart from some hackey function
advising to signal instead of calling `read_minibuf_noninteractive()`.

I am inclined to go with GP's shunting of stdin to /dev/null to avoid having
to change the C code.  Most well behaved server daemons will do that... shunt
stdin to /dev/null I mean.

Re: Really noninteractive

[Noam Postavsky]

On Thu, 20 Feb 2020 at 14:11, <dick.r.chiang@gmail.com> wrote:
>
> LI> Yes, but that's not what I want.  :-) I want to say "this function call,
> LI> in this otherwise totally normal Emacs, should not prompt".
>
> Okay, so you've established that `noninteractive` only diverts "normal emacs"
> to call `read_minibuf_noninteractive()` which in turn attempts to get input
> from stdin

See, I assumed this as well after reading the prior messages of this
thread. But I just tried it out now, and it actually does not do any
diversion. I'm actually not entirely sure why, I guess changes to the
`noninteractive' variable from lisp don't reach the C level?

So the redirection of stdin only helps in the --batch case.

Re: Really noninteractive

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Fri, 21 Feb 2020 08:20:48 -0500
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Ihor Radchenko <yantar92@gmail.com>,
>  emacs-devel <emacs-devel@gnu.org>
> 
> I guess changes to the `noninteractive' variable from lisp don't
> reach the C level?

I don't think this variable was supposed to be set from Lisp at all.

Re: Really noninteractive

[Andreas Schwab]

On Feb 20 2020, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@suse.de> writes:
>
>>> I'm trying to use Emacs from a server context, and would prefer that
>>> Emacs signal an error whenever you tell it to do something interactive
>>> rather than hang forever.
>>
>> Run emacs in batch mode.
>
> I don't want to do that -- I just want to ensure that certain code paths
> aren't interactive.

Set standard-input to a function that throws.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Really noninteractive

[Noam Postavsky]

On Mon, 24 Feb 2020 at 04:17, Andreas Schwab <schwab@suse.de> wrote:

> > I don't want to do that -- I just want to ensure that certain code paths
> > aren't interactive.
>
> Set standard-input to a function that throws.

`read-string' doesn't use `standard-input'. I think only `read' does.

Re: Really noninteractive

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> `read-string' doesn't use `standard-input'. I think only `read' does.

Indeed.

By the way, the doc string for read is oddly phrased:

STREAM or the value of ‘standard-input’ may be:
 a buffer (read from point and advance it)
 a marker (read from where it points and advance it)
 a function (call it with no arguments for each character,
     call it with a char as argument to push a char back)
 a string (takes text from string, starting at the beginning)
 t (read text line using minibuffer and use it, or read from
    standard input in batch mode).

All of these are odd, but the "call it with no arguments" etc is
particularly befuddling.  I think what happens is that the function is
called with no arguments, and should return a character (and so on)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no