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

Full log

Message #35 received at 33016 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33016 <at> debbugs.gnu.org, Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
Subject: Re: 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

[Message part 1 (text/plain, inline)]

On Thu, 11 Apr 2019 at 10:05, Eli Zaretskii <eliz <at> 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.

[reset-when-entered.debugger.diff (application/octet-stream, attachment)]

Previous Next

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