GNU bug report logs - #33016
26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist

Previous Next

Package: emacs;

Reported by: Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>

Date: Thu, 11 Oct 2018 12:57:01 UTC

Severity: minor

Tags: fixed

Found in version 26.1

Fixed in version 27.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33016 <at> debbugs.gnu.org, bauer.klaus.dieter <at> gmail.com
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 <at> gmail.com>
> Date: Wed, 10 Apr 2019 17:58:43 -0400
> Cc: Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>, 33016 <at> 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.




This bug report was last modified 6 years and 73 days ago.

Previous Next


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