[Top][All Lists]

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

bug#33016: 26.1; (make-process ...) doesn't signal an error, when execut

From: Eli Zaretskii
Subject: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist
Date: Thu, 11 Apr 2019 17:04:46 +0300

> From: Noam Postavsky <address@hidden>
> Date: Wed, 10 Apr 2019 17:58:43 -0400
> Cc: Klaus-Dieter Bauer <address@hidden>, address@hidden
> I was inspired by your suggestions to think of a simpler idea: use 
> "C:/nul.exe".
> There is unfortunately one additional wrinkle: each of the test passes
> on its own, but when running both together the second one fails due to
> this check in maybe_call_debugger:
>       /* RMS: What's this for?  */
>       && when_entered_debugger < num_nonmacro_input_events)
> RMS' question is (now) answered in the commentary for when_entered_debugger:
> /* The value of num_nonmacro_input_events as of the last time we
>    started to enter the debugger.  If we decide to enter the debugger
>    again when this is still equal to num_nonmacro_input_events, then we
>    know that the debugger itself has an error, and we should just
>    signal the error instead of entering an infinite loop of debugger
>    invocations.  */
> static intmax_t when_entered_debugger;
> So I guess we'd need some way of resetting it from Lisp?

Doesn't it work to simply set its value before the second test?

> As far as I can tell, the normal debugger resets it by calling
> recursive-edit, but there's no way to return from that without human
> intervention (I think?).

Doesn't abort-recursive-edit work noninteractively?

> +                    ;; On Windows, "nul.FOO" is the empty file for any
> +                    ;; FOO, in any directory.  So this passes Emacs'

Instead of "is the empty file", I'd say something like "resolves to
the null device, reading from which sets the EOF condition".


reply via email to

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