unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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: Thu, 11 Apr 2019 13:34:25 -0400	[thread overview]
Message-ID: <CAM-tV-9TsiGBVEPCxHX4FJP1aNTU4PAXcUc6a5fMmZH8SWqsrw@mail.gmail.com> (raw)
In-Reply-To: <8336mo63k1.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Thu, 11 Apr 2019 at 10:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > 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?

Yes, or in each test, since the tests don't necessarily have knowledge
of what order they're called in (I think it's currently alphabetical
order of test name). See attached diff (against the state of my v3
patch), but it seems a bit silly to make the variable Lisp accessible
just for this obscure test case. I don't see any other way though.

> > 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?

Yes, but how can I arrange for it to be called without stopping to
read commands from the user first? E.g., in the following
abort-recursive-edit is too late to do any good:

(progn
  (recursive-edit)
  (abort-recursive-edit))

Using pre-command-hook is also too late, the user has to type
something to trigger the beginning of a certain command first.

(let ((pre-command-hook #'abort-recursive-edit))
  (recursive-edit))

> > +                    ;; 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".

Hmm, while technically more accurate, it seems like a little too much
detail to be useful; I think saying "acts like an always-empty file"
should be enough.

[-- Attachment #2: reset-when-entered.debugger.diff --]
[-- Type: application/octet-stream, Size: 3234 bytes --]

diff --git i/src/.gdbinit w/src/.gdbinit
index b8b3031..32b2680 100644
--- i/src/.gdbinit
+++ w/src/.gdbinit
@@ -1227,6 +1227,7 @@ if defined_HAVE_X_WINDOWS
   break x_error_quitter
 end
 
+break Fredraw_display
 
 # Put the Python code at the end of .gdbinit so that if GDB does not
 # support Python, GDB will do all the above initializations before
diff --git i/src/eval.c w/src/eval.c
index e9f118c..6c1a2bb 100644
--- i/src/eval.c
+++ w/src/eval.c
@@ -59,7 +59,7 @@ Lisp_Object Vrun_hooks;
    signal the error instead of entering an infinite loop of debugger
    invocations.  */
 
-static intmax_t when_entered_debugger;
+//static intmax_t when_entered_debugger;
 
 /* The function from which the last `signal' was called.  Set in
    Fsignal.  */
@@ -4170,6 +4170,12 @@ Note that `debug-on-error', `debug-on-quit' and friends
 still determine whether to handle the particular condition.  */);
   Vdebug_on_signal = Qnil;
 
+  DEFSYM (Qwhen_entered_debugger, "when-entered-debugger");
+  DEFVAR_INT ("when-entered-debugger", when_entered_debugger,
+              doc: /* The number of keyboard events as of last time `debugger' was called.
+Used to avoid infinite loops if the debugger itself has an error.
+Don't set this unless you're sure that can't happen.  */);
+
   /* When lexical binding is being used,
    Vinternal_interpreter_environment is non-nil, and contains an alist
    of lexically-bound variable, or (t), indicating an empty
diff --git i/test/src/callproc-tests.el w/test/src/callproc-tests.el
index a2728a3..28f7975 100644
--- i/test/src/callproc-tests.el
+++ w/test/src/callproc-tests.el
@@ -43,7 +43,12 @@
   (skip-unless (eq system-type 'windows-nt))
   (let* ((debug-on-error t)
          (have-called-debugger nil)
-         (debugger (lambda (&rest _) (setq have-called-debugger t))))
+         (debugger (lambda (&rest _)
+                     (setq have-called-debugger t)
+                     ;; Allow entering the debugger later in the same
+                     ;; test run, before going back to the command
+                     ;; loop.
+                     (setq when-entered-debugger -1))))
     (should (eq :got-error ;; NOTE: `should-error' would inhibit debugger.
                 (condition-case-unless-debug ()
                     ;; On Windows, "nul.FOO" is the empty file for any
diff --git i/test/src/process-tests.el w/test/src/process-tests.el
index 25a52b7..640f292 100644
--- i/test/src/process-tests.el
+++ w/test/src/process-tests.el
@@ -220,7 +220,12 @@ process-tests--mixable
   (skip-unless (eq system-type 'windows-nt))
   (let* ((debug-on-error t)
          (have-called-debugger nil)
-         (debugger (lambda (&rest _) (setq have-called-debugger t))))
+         (debugger (lambda (&rest _)
+                     (setq have-called-debugger t)
+                     ;; Allow entering the debugger later in the same
+                     ;; test run, before going back to the command
+                     ;; loop.
+                     (setq when-entered-debugger -1))))
     (should (eq :got-error ;; NOTE: `should-error' would inhibit debugger.
                 (condition-case-unless-debug ()
                     ;; Emacs doesn't search for absolute filenames, so

  reply	other threads:[~2019-04-11 17:34 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
2019-04-11 14:04           ` Eli Zaretskii
2019-04-11 17:34             ` Noam Postavsky [this message]
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM-tV-9TsiGBVEPCxHX4FJP1aNTU4PAXcUc6a5fMmZH8SWqsrw@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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).