From: Noam Postavsky <npostavs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer <bauer.klaus.dieter@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: Wed, 10 Apr 2019 17:58:43 -0400 [thread overview]
Message-ID: <CAM-tV--z5RgQSRTyjXE9JmuP8pHsZaZ4k4DGz3Ye=rx7m3BF5g@mail.gmail.com> (raw)
In-Reply-To: <83bm1f6yfl.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
On Tue, 9 Apr 2019 at 10:33, Eli Zaretskii <eliz@gnu.org> wrote:
> > but I can't see a way to trigger
> > this for call_process: it searches for PROGRAM and signals an error
> > early, regardless of whether the filename is absolute or not.
>
> One way is to delete the program between the time Emacs searches for
> it and the time it actually invokes it. Another way is to make the
> program be a file whose name includes non-ASCII characters outside of
> the current system codepage (I'm assuming the search for the program
> uses file-oriented primitives which support any Unicode characters).
>
> Having said that, this isn't worth too much of your time, if those
> ideas cannot be easily implemented, or turn out wrong, and no others
> present themselves.
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? (which does
open the tiny danger of a debugger inf-looping by resetting
when_entered_debugger and then hitting an error).
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?).
[-- Attachment #2: v3-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch --]
[-- Type: application/x-patch, Size: 6209 bytes --]
next prev parent reply other threads:[~2019-04-10 21:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 12:55 bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist Klaus-Dieter Bauer
2018-10-11 14:22 ` Eli Zaretskii
2018-10-19 8:03 ` Klaus-Dieter Bauer
2018-10-19 8:30 ` Eli Zaretskii
2019-04-08 18:34 ` Noam Postavsky
2019-04-08 18:58 ` Eli Zaretskii
2019-04-09 14:13 ` Noam Postavsky
2019-04-09 14:33 ` Eli Zaretskii
2019-04-10 21:58 ` Noam Postavsky [this message]
2019-04-11 14:04 ` Eli Zaretskii
2019-04-11 17:34 ` Noam Postavsky
2019-04-11 17:55 ` Eli Zaretskii
2019-04-12 0:44 ` Noam Postavsky
2019-04-12 8:44 ` Eli Zaretskii
2019-04-12 18:20 ` Noam Postavsky
2019-04-12 18:44 ` Eli Zaretskii
2019-04-15 12:21 ` Noam Postavsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM-tV--z5RgQSRTyjXE9JmuP8pHsZaZ4k4DGz3Ye=rx7m3BF5g@mail.gmail.com' \
--to=npostavs@gmail.com \
--cc=33016@debbugs.gnu.org \
--cc=bauer.klaus.dieter@gmail.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.