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

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
Cc: 33016 <at> debbugs.gnu.org
Subject: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist
Date: Fri, 19 Oct 2018 11:30:33 +0300

> From: Klaus-Dieter Bauer <bauer.klaus.dieter <at> gmail.com>
> Date: Fri, 19 Oct 2018 10:03:00 +0200
> Cc: 33016 <at> debbugs.gnu.org
> 
> On Unix, the elisp will succeed, but the output and exit-status of the process clarify the issue.
> On Windows, a non-local exit occurs due to the resulting exception.
> As example:
> 
>      (let (p)
>        (setq p
>          (make-process :name "test" :command '("/tmp/nosuchcommand") :buffer (current-buffer)))
>        ;; -- Subsequent code never reached on Windows
>        (while (process-live-p p)
>          (sleep-for 0.01))
>        (message "(Process exit status %d)"
>          (process-exit-status p)))
> 
> So on Windows two issues occur:
>   - The exception doesn't indicate what went wrong.
>   - The control-flow of the Elisp program is different from Unix.
> 
> This different seems, like it may give rise to Windows-specific bugs, that would be unnecessarily hard to
> debug.

That's true, but the way Emacs invokes async subprocesses on Windows
cannot be similar to Unix, because Windows lacks the 'fork' system
call.  Therefore, on Windows, the Emacs process itself invokes the
program, whereas on Unix this is done by a separate "forked" process,
which means Emacs on Unix simply doesn't know whether running the
program failed, until much later.

What this means is if some Lisp program wants to produce a consistent
behavior in these situations, it should have slightly different
application-level code for Posix and non-Posix hosts.

> Then again, calling programs by full path is probably rare, so it's probably a pretty low-priority issue.

Right.

Previous Next

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