[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 <npostavs@gmail.com>
> Date: Wed, 10 Apr 2019 17:58:43 -0400
> Cc: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>, 33016@debbugs.gnu.org
>
> 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".
Thanks.
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/08
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Eli Zaretskii, 2019/04/08
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/09
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Eli Zaretskii, 2019/04/09
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/10
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist,
Eli Zaretskii <=
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/11
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Eli Zaretskii, 2019/04/11
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/11
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Eli Zaretskii, 2019/04/12
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/12
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Eli Zaretskii, 2019/04/12
- bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist, Noam Postavsky, 2019/04/15