From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 11 08:56:08 2018 Received: (at submit) by debbugs.gnu.org; 11 Oct 2018 12:56:08 +0000 Received: from localhost ([127.0.0.1]:44260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAaVb-0007lo-UK for submit@debbugs.gnu.org; Thu, 11 Oct 2018 08:56:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAaVZ-0007lL-Tn for submit@debbugs.gnu.org; Thu, 11 Oct 2018 08:56:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gAaVT-0005Vk-BT for submit@debbugs.gnu.org; Thu, 11 Oct 2018 08:56:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52817) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gAaVT-0005Vg-7o for submit@debbugs.gnu.org; Thu, 11 Oct 2018 08:55:59 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gAaVR-000361-QI for bug-gnu-emacs@gnu.org; Thu, 11 Oct 2018 08:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gAaVQ-0005UK-8t for bug-gnu-emacs@gnu.org; Thu, 11 Oct 2018 08:55:57 -0400 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:41355) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gAaVP-0005Tm-Rl for bug-gnu-emacs@gnu.org; Thu, 11 Oct 2018 08:55:56 -0400 Received: by mail-lj1-x229.google.com with SMTP id u21-v6so8099039lja.8 for ; Thu, 11 Oct 2018 05:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lKO5etwMJstnqaCFD5MT9YH7nLBx6HexXgjvpy52izc=; b=bCBTbgaT/4MoXCiB8LBNiFyYgxzBZl7r3HmZ4z5c95HjeeBCyORREMvDEmPuXAazf7 /Yhp/xRzpBLRv9bKGyfHT9lWrO1k6tk1XHGQGKdIzm/hSBcmQjyt6XTp5O9JAffJYaq+ cm28rnkoqP7xsX24W/WPJDmW5mCvJhxeVeuJxvdwsQvSmOKHfsiGIEVBuEm69UzrO0+w hwEylM8wrBUfdpIHES6jdNW6YfuFFxCIe3qamUmr+LkDMjstnqAmAgMXQGT1zx08VISU etlXZSVPW1br4UTtNThicdQ09xWJ47uTL2It1Y+DjEPJbFO0cROzGKnxN8gTnt2ykrf+ Mp7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lKO5etwMJstnqaCFD5MT9YH7nLBx6HexXgjvpy52izc=; b=PK7qtiuMAbnl9dGD5rBFh1DIj4B/z5c7fZR4EFqY93ERzQNYk2cuwXVqumA6Dvr7ta d+uEz5qt68e+FIoLw/xRUIxPaUcO3qA7V49n+T9rzse7r45dcVfmADza1N0mcmN22Pgc l9lqgybZaqZZ4347WMtFcM8ImtQmmsv6Xzj+5MdUeFYGwRBdS1A7oQr9hUDemd+12liM 2axfPHfFC3MVTGNCrYifluqVtIsEcTdeqKy7CKO46oz8ABP7wG1Qm/cV4pY10o2TesoB iYgTsOp6I30WZ8uD16gQ5DasStYicy6PSZwnWCQB6O5aKM/Do457tYYaWufgAAcKQGZF Y7HA== X-Gm-Message-State: ABuFfohz/QrnYx6+jiwjgw+drmND7QR6/5QBG4Saho0zXDx79HA5M9j5 aZZrJNj2/KmmWFXzRSv5dy3CTl9q2L7NVm1gS2v4HAp5 X-Google-Smtp-Source: ACcGV60sI4hghSLSnMof19scSaUN5G4txhzlwytkLUX8epW8kEElD+zbFAHYzX/DjBrBP9vWJCjy+jjbS9CN4wmDY3M= X-Received: by 2002:a2e:9d8a:: with SMTP id c10-v6mr1241289ljj.2.1539262553935; Thu, 11 Oct 2018 05:55:53 -0700 (PDT) MIME-Version: 1.0 From: Klaus-Dieter Bauer Date: Thu, 11 Oct 2018 14:55:27 +0200 Message-ID: Subject: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000be53090577f37d03" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) --000000000000be53090577f37d03 Content-Type: text/plain; charset="UTF-8" The error-handling of `make-process' for a non-existents executable is inconsistent between invocation as a command (on PATH) and invocation as a full path. To reproduce, start `emacs -Q'. Entering M-x eval-expression RET (make-process :name "test" :command '("No Such Command")) will bring up the debugger with (file-missing "Searching for program" "No such file or directory" "nosuchcommand") However, entering M-x eval-expression RET (make-process :name "test" :command '("c:/No Such Command")) will merely display in the echo-area message: eval: Spawning child process: Invalid argument I stumbled upon this when debugging a quick-and-dirty script, that called a program by absolute path. When a new version of the program changed the name of the executable (tex2lyx2.3 -> tex2lyx), this issue occurred, and hindered debugging the problem. The wording of the message might indicate a Windows-specific issue. regards, Klaus In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 built on CIRROCUMULUS Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor 'Microsoft Corp.', version 10.0.17134 Recent messages: (#> #) Quit Entering debugger... Back to top level eval: Spawning child process: Invalid argument Quit Type C-x 1 to delete the help window, C-M-v to scroll help. Quit Entering debugger... Back to top level read--expression: Trailing garbage following expression Configured using: 'configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install 'CFLAGS=-O2 -static -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2 Important settings: value of $LANG: ENU locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny seq dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-extra help-fns radix-tree help-mode easymenu cl-print byte-opt gv bytecomp byte-compile cl-loaddefs cl-lib cconv debug elec-pair time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 100958 5519) (symbols 56 20557 1) (miscs 48 45 202) (strings 32 31151 1771) (string-bytes 1 808081) (vectors 16 14466) (vector-slots 8 493429 6988) (floats 8 53 305) (intervals 56 327 7) (buffers 992 14)) --000000000000be53090577f37d03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The error-handling of `make-process' for a non-existents
executable is incons= istent between invocation as a command
(on PATH) and invocation as a full path.
=
To reproduce, start `emacs -Q'.

Entering

=C2=A0 =C2=A0 = M-x eval-expression RET

will brin= g up the debugger with=C2=A0

=C2=A0 =C2= =A0 (file-missing "Searching for program" "No such file or d= irectory" "nosuchcommand")

However, entering
<= br>
=C2=A0 =C2=A0 M-x = eval-expression RET=C2=A0
=C2=A0 =C2=A0 =C2=A0 (make-process :name "test" :command '= ;("c:/No Such Command"))

will= merely display in the echo-area message:

=C2=A0 =C2=A0 eval: Spawning child process: Invalid argument

I stumbled upon this when debugging a quick-and-d= irty
script, that call= ed a program by absolute path. When a new
version of the program changed the name of the executab= le
(tex2lyx2.3 -> t= ex2lyx), this issue occurred, and hindered
debugging the problem.

The wording of the message might indicate a=C2=A0
Windows-specific issue.
<= font face=3D"monospace, monospace">
regards, Klaus



<= font face=3D"monospace, monospace">In GNU Emacs 26.1 (build 1, x86_64-w64-m= ingw32)
=C2=A0of 2018-= 05-30 built on CIRROCUMULUS
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea<= /div>
Windowing system distributor = 'Microsoft Corp.', version 10.0.17134
Recent messages:
(#<process test<1>> #<process test>)=
Quit
Entering debugger...
= Back to top level
eval: Spawning child process: Invalid argum= ent
Quit
<= div>Type C-x 1 to delete the help windo= w, C-M-v to scroll help.
Quit
Entering debug= ger...
Back to top lev= el
read--expression: T= railing garbage following expression
Configured using:
=C2=A0'configure --without-dbus --host=3Dx86_64-w64-mingw32<= /font>
=C2=A0--without-compre= ss-install 'CFLAGS=3D-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB<= /font>
TOOLKIT_SCROLL_BARS TH= READS LCMS2

Important settings:<= /div>
=C2=A0 value of $LANG: ENU
=C2=A0 locale-coding-sys= tem: cp1252

Major mode: Lisp Interactio= n

Minor modes in effect:
=C2=A0 tooltip-mode: t
<= div>=C2=A0 global-eldoc-mode: t<= /div>
=C2=A0 eldoc-mode: t
=C2=A0 electric-indent-mode: t=
=C2=A0 mouse-wheel-mo= de: t
=C2=A0 tool-bar-= mode: t
=C2=A0 menu-ba= r-mode: t
=C2=A0 file-= name-shadow-mode: t
= =C2=A0 global-font-lock-mode: t
=C2=A0 font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-mode: t
=C2=A0 line-number-mode: t<= /font>
=C2=A0 transient-mark-= mode: t

Load-path shadows:
=
None found.

Features:
dired-loaddefs format-spec rfc822 mm= l mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-b= odies
mm-encode mail-p= arse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prs= vr mail-utils cl-extra
help-fns radix-tree help-mode easymenu cl-print byte-opt gv bytecomp
byte-compile cl-loaddefs cl= -lib cconv debug elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hook= s
lisp-float-type mwhe= el dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset = image regexp-opt fringe
prog-mode register page menu-b= ar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core=
term/tty-colors frame= cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japan= ese eucjp-ms cp51932
h= ebrew greek romanian slovak czech european ethiopic indian cyrillic<= /div>
chinese composite charscript = charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nad= vice loaddefs
button f= aces cus-face macroexp files text-properties overlay sha1 md5
<= div>base64 format env code-pages mule c= ustom widget hashtable-print-readable
backquote w32notify w32 lcms2 multi-tty make-network-proces= s emacs)

Memory information:
((conses 16 100958 5519)<= /div>
=C2=A0(symbols 56 20557 1)
=C2=A0(miscs 48 45 202)<= /font>
=C2=A0(strings 32 3115= 1 1771)
=C2=A0(string-= bytes 1 808081)
=C2=A0= (vectors 16 14466)
=C2= =A0(vector-slots 8 493429 6988)
=C2=A0(floats 8 53 305)
=C2=A0(intervals 56 327 7)
=C2=A0(buffers 992 14))

<= /div> --000000000000be53090577f37d03-- From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 11 10:22:37 2018 Received: (at 33016) by debbugs.gnu.org; 11 Oct 2018 14:22:37 +0000 Received: from localhost ([127.0.0.1]:45347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAbrJ-0001du-CU for submit@debbugs.gnu.org; Thu, 11 Oct 2018 10:22:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gAbrH-0001dh-LQ for 33016@debbugs.gnu.org; Thu, 11 Oct 2018 10:22:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gAbr5-0001ZV-Sg for 33016@debbugs.gnu.org; Thu, 11 Oct 2018 10:22:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gAbr5-0001Ye-1p; Thu, 11 Oct 2018 10:22:23 -0400 Received: from [176.228.60.248] (port=3843 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gAbr3-0000QR-SY; Thu, 11 Oct 2018 10:22:22 -0400 Date: Thu, 11 Oct 2018 17:22:22 +0300 Message-Id: <835zy8y34x.fsf@gnu.org> From: Eli Zaretskii To: Klaus-Dieter Bauer In-reply-to: (message from Klaus-Dieter Bauer on Thu, 11 Oct 2018 14:55:27 +0200) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Klaus-Dieter Bauer > Date: Thu, 11 Oct 2018 14:55:27 +0200 > > Entering > > M-x eval-expression RET > (make-process :name "test" :command '("No Such Command")) > > will bring up the debugger with > > (file-missing "Searching for program" "No such file or directory" "nosuchcommand") > > However, entering > > M-x eval-expression RET > (make-process :name "test" :command '("c:/No Such Command")) > > will merely display in the echo-area message: > > eval: Spawning child process: Invalid argument > > I stumbled upon this when debugging a quick-and-dirty > script, that called a program by absolute path. When a new > version of the program changed the name of the executable > (tex2lyx2.3 -> tex2lyx), this issue occurred, and hindered > debugging the problem. > > The wording of the message might indicate a > Windows-specific issue. The error in the second case is Windows specific, but the inconsistency isn't: on Unix the second case "succeeds", in that it returns a process object without any error messages. The error message you see in the first case is because Emacs searches for the program along exec-path (because it is not an absolute file name). In the second case this search is not done, because the file name is already absolute. So I don't think this is a bug. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 19 04:03:37 2018 Received: (at 33016) by debbugs.gnu.org; 19 Oct 2018 08:03:37 +0000 Received: from localhost ([127.0.0.1]:58095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDPku-00084o-Lf for submit@debbugs.gnu.org; Fri, 19 Oct 2018 04:03:36 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:41327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDPkr-00084V-F0 for 33016@debbugs.gnu.org; Fri, 19 Oct 2018 04:03:35 -0400 Received: by mail-lf1-f53.google.com with SMTP id q39-v6so24532214lfi.8 for <33016@debbugs.gnu.org>; Fri, 19 Oct 2018 01:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r7sAJzHj7M/7quSh10nVwVIAUCLJ1xYSm5NO3s4Fkh4=; b=HYlt8XA7vt7r4Q15HDtm8D1+uMHmh0gyui4255JxaRzLA0J9cINGx7I1h59be7jZH1 NpQ/tMHiC1VPsUZD1a/z2D/3ctfoaYF54l49m6Djo2zAypU0g/PLY4sX6a6n54wl76cM s7vISl3N80MPhrxn/hxww/IVHlMdZPXVMGNDTnxdUkd/T6svnHSvRm+DpSQcYE2HMpWD 2bwyJRWu3tApj2Bei6WjW5pWW3PRebM3GiYSpVDML8lOpfxxfQjrYfUP+wi9lqvO5fxo rnduZ9TmZnXydYS6NilxzaBzIhIHsASA9zPOV//6mN6Bpm+5qSQTkWcQaHcqrQKTrAuQ U8hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r7sAJzHj7M/7quSh10nVwVIAUCLJ1xYSm5NO3s4Fkh4=; b=QWjlj6GV2ElTiuFeAbPtBWtHZwxGTX3hS+S7hipf0NqBmVKNlbq0Pj3CNfm+a1ZgEf vnppHCSYkWK61DZD/8IDET03B2EdP5w/vYOplFSxRbE6hMxtBwWG71jhWQ4rhhXxaXq1 cquYovsAp2MJ20pCOt4pz7GdFwLNNOjCdyj9MoAKX4WjO6uueufVLSPDrexIIeRvtkA/ FZJH8AdXldUiHZjJcPuy9uryluKQtm/prBW5rBAUDLqb8tnB8GE3IeRitiqyBiRJp4oq RMbgu7vE0pPcmBz1LZ4GFT/82PvqcSNGAovkcE6q500pWQfuQMrFoyLYl1tIbFOAvibk Q85w== X-Gm-Message-State: ABuFfohNM0I9fFmjAsEy5ePBvLouBPyWiDCKS6L/nCexTX9VGle77P1q 9Zimu+VUe5SBxrEN2wPcsbgeKXox7lwr9IUgcTE= X-Google-Smtp-Source: ACcGV62oVxhpJOv4BPjz41IwITXRIJ0z+O/lRMDtUSDNCeVMxC3PuDaQWP9Ee2sMIH9IT66eiILrJu8jV6JO3fPACfc= X-Received: by 2002:a19:288c:: with SMTP id o134-v6mr2503665lfo.124.1539936207357; Fri, 19 Oct 2018 01:03:27 -0700 (PDT) MIME-Version: 1.0 References: <835zy8y34x.fsf@gnu.org> In-Reply-To: <835zy8y34x.fsf@gnu.org> From: Klaus-Dieter Bauer Date: Fri, 19 Oct 2018 10:03:00 +0200 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000009dcace057890569b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000009dcace057890569b Content-Type: text/plain; charset="UTF-8" On Thu, Oct 11, 2018 at 4:22 PM Eli Zaretskii wrote: > > From: Klaus-Dieter Bauer > > Date: Thu, 11 Oct 2018 14:55:27 +0200 > > > > Entering > > > > M-x eval-expression RET > > (make-process :name "test" :command '("No Such Command")) > > > > will bring up the debugger with > > > > (file-missing "Searching for program" "No such file or directory" > "nosuchcommand") > > > > However, entering > > > > M-x eval-expression RET > > (make-process :name "test" :command '("c:/No Such Command")) > > > > will merely display in the echo-area message: > > > > eval: Spawning child process: Invalid argument > > > > I stumbled upon this when debugging a quick-and-dirty > > script, that called a program by absolute path. When a new > > version of the program changed the name of the executable > > (tex2lyx2.3 -> tex2lyx), this issue occurred, and hindered > > debugging the problem. > > > > The wording of the message might indicate a > > Windows-specific issue. > > The error in the second case is Windows specific, but the > inconsistency isn't: on Unix the second case "succeeds", in that it > returns a process object without any error messages. > > The error message you see in the first case is because Emacs searches > for the program along exec-path (because it is not an absolute file > name). In the second case this search is not done, because the file > name is already absolute. > > So I don't think this is a bug. > Now I understand the intent of the implementation better. However, the Unix/Windows difference still seems like a bug to me. 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. Then again, calling programs by full path is probably rare, so it's probably a pretty low-priority issue. - Klaus --0000000000009dcace057890569b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 11, 2018 at 4:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Klaus-D= ieter Bauer <bauer.klaus.dieter@gmail.com>
> Date: Thu, 11 Oct 2018 14:55:27 +0200
>
> Entering
>
>=C2=A0 =C2=A0 =C2=A0M-x eval-expression RET
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(make-process :name "test" :comman= d '("No Such Command"))
>
> will bring up the debugger with
>
>=C2=A0 =C2=A0 =C2=A0(file-missing "Searching for program" &qu= ot;No such file or directory" "nosuchcommand")
>
> However, entering
>
>=C2=A0 =C2=A0 =C2=A0M-x eval-expression RET
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(make-process :name "test" :comman= d '("c:/No Such Command"))
>
> will merely display in the echo-area message:
>
>=C2=A0 =C2=A0 =C2=A0eval: Spawning child process: Invalid argument
>
> I stumbled upon this when debugging a quick-and-dirty
> script, that called a program by absolute path. When a new
> version of the program changed the name of the executable
> (tex2lyx2.3 -> tex2lyx), this issue occurred, and hindered
> debugging the problem.
>
> The wording of the message might indicate a
> Windows-specific issue.

The error in the second case is Windows specific, but the
inconsistency isn't: on Unix the second case "succeeds", in t= hat it
returns a process object without any error messages.

The error message you see in the first case is because Emacs searches
for the program along exec-path (because it is not an absolute file
name).=C2=A0 In the second case this search is not done, because the file name is already absolute.

So I don't think this is a bug.

Now= I understand the intent of the implementation better. However, the Unix/Wi= ndows difference still seems like a bug to me.

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 th= e resulting exception.
As example:

=C2=A0 =C2=A0 (let (p)
=C2=A0 = =C2=A0 =C2=A0 (setq p
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (make-process :name &quo= t;test" :command '("/tmp/nosuchcommand") :buffer (curren= t-buffer)))
=C2=A0 =C2=A0 =C2=A0 ;; -- Subsequent code never reached on Wi= ndows
=C2=A0 =C2=A0 =C2=A0 (while (process-live-p p)
=C2=A0 =C2=A0 =C2=A0= =C2=A0 (sleep-for 0.01))
=C2=A0 =C2=A0 =C2=A0 (message "(Process exi= t status %d)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (process-exit-status p)))
=

So on Windows two issues occ= ur:
=C2=A0 - The exception doesn't indicate what went wrong.<= /div>
=C2=A0 - 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.
<= div>
Then again, calling programs by full path is probably ra= re, so it's probably a pretty low-priority issue.

<= div>- Klaus

=C2=A0
--0000000000009dcace057890569b-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 19 04:31:07 2018 Received: (at 33016) by debbugs.gnu.org; 19 Oct 2018 08:31:07 +0000 Received: from localhost ([127.0.0.1]:58114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDQBX-0000MO-4M for submit@debbugs.gnu.org; Fri, 19 Oct 2018 04:31:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDQBU-0000Ls-Vb for 33016@debbugs.gnu.org; Fri, 19 Oct 2018 04:31:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDQBL-0005A9-R8 for 33016@debbugs.gnu.org; Fri, 19 Oct 2018 04:30:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDQBL-00058Y-H4; Fri, 19 Oct 2018 04:30:55 -0400 Received: from [176.228.60.248] (port=4513 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gDQBK-0002HL-W6; Fri, 19 Oct 2018 04:30:55 -0400 Date: Fri, 19 Oct 2018 11:30:33 +0300 Message-Id: <83y3aupcd2.fsf@gnu.org> From: Eli Zaretskii To: Klaus-Dieter Bauer In-reply-to: (message from Klaus-Dieter Bauer on Fri, 19 Oct 2018 10:03:00 +0200) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <835zy8y34x.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Klaus-Dieter Bauer > Date: Fri, 19 Oct 2018 10:03:00 +0200 > Cc: 33016@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. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 14:35:01 2019 Received: (at 33016) by debbugs.gnu.org; 8 Apr 2019 18:35:01 +0000 Received: from localhost ([127.0.0.1]:50178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDZ6j-0002Jf-2U for submit@debbugs.gnu.org; Mon, 08 Apr 2019 14:35:01 -0400 Received: from mail-ot1-f49.google.com ([209.85.210.49]:34611) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDZ6h-0002JP-Jz for 33016@debbugs.gnu.org; Mon, 08 Apr 2019 14:35:00 -0400 Received: by mail-ot1-f49.google.com with SMTP id k21so13163659otf.1 for <33016@debbugs.gnu.org>; Mon, 08 Apr 2019 11:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UhE2mPbSe5akH5Xtz6cswOmB0/U2E4ICDvO05ot3JiA=; b=iDxu9894gGvCPWYFOHVWMBmLeBNnv+g1NNPJtca2/heUBsHKXn1t0LbPZrAY8j/wyB IUEpFZOFrCxRSi4PCZ1Wr57+6EW6NGeeywryWIzsKVbxXeCZT31/LjT2bcDXuXbx1koY zdvhqkH/OR2dTWAxnjrtVWapIrCWl7m5kyWkEVE+MaGODV2RWLa2kKCMFld4RqZrN8Kg 7DWJwmjSzzRjqRacz/xgT5ZoGLCVS1OasZP2/j7+hwI4ft+tGhz21QkGek9Ai7pwEJsg 2wGAHFG4De9xaWvTPIvFpHUOWrfsPga045v2NcEeQ0CfWbmBwRX1ReIv+7WgD+1ijFvd 4OmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UhE2mPbSe5akH5Xtz6cswOmB0/U2E4ICDvO05ot3JiA=; b=K2zk6eTZYdy4b1cNqsSduz2hDuC9WUFMaQ6cqKXNuSZgMj62zcc2F/Iu8+9cR/mHwe Nu21V+G3zQ8JB+9kKmHBHxjdcki4obZ5y3u2eNplITqMP1ka1vzPICmlbzrBDNxYd8nh HPwASEoGvUkn0KCGMaVBCn5xK7bQEGPi7TlKgbrSOeicnWbNyIhkmJI6oy5QD05edlVb 63X7Rm0tRjXDuUSPYStofGNvw36Kz5RK83bIE1ASowajpd2iKnIjrfDcCu+Ilp60mI6y EoTP03105hSwWty1hwh2ycpwAJHUhONrQgIReRk4g2NSQDUXkFQ1RLd5zXyaKndZn4N0 e1bg== X-Gm-Message-State: APjAAAUpS2ef8KNhJJSNR4oK7p3jqlZKjMbJ2uLwyF2HUDEUWsAGqQns H2EU2BHEV6D/a9fCMya2FrxR4zMaNNNWvqJunzE= X-Google-Smtp-Source: APXvYqxxa4QfTMgck8w7/uy8DxJg3Tt1Nk5XlyT2o8m+setxDIXx/YwBwqTUCOSlSxgupf75w2J8JQjsyEMgvIeBGIE= X-Received: by 2002:a9d:7749:: with SMTP id t9mr20846542otl.229.1554748492803; Mon, 08 Apr 2019 11:34:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Noam Postavsky Date: Mon, 8 Apr 2019 14:34:41 -0400 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Klaus-Dieter Bauer Content-Type: multipart/mixed; boundary="000000000000a10e360586091718" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000a10e360586091718 Content-Type: text/plain; charset="UTF-8" On Thu, 11 Oct 2018 at 08:57, Klaus-Dieter Bauer wrote: > M-x eval-expression RET > (make-process :name "test" :command '("c:/No Such Command")) > > will merely display in the echo-area message: > > eval: Spawning child process: Invalid argument The confusing thing here is that the error is signaled between block_input()...unblock_input(), which prevents the debugger from triggering. E.g., the "-unless-debug" part in the expression below appears not to work, even though the error flows normally in other respects: (condition-case-unless-debug err (make-process :name "test" :command '("c:/No Such Command")) (error (list :error err))) ;=> (:error (file-error "Spawning child process" "Invalid argument")) The attached patch fixes this by moving the signal to after the unblock_input(). --000000000000a10e360586091718 Content-Type: application/octet-stream; name="v1-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Disposition: attachment; filename="v1-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ju8p0vp60 RnJvbSBkODcxNmMxNDA2MzAxNTEyZmJiZmNlN2YxZWViNDVmYzhkNTMxZmQxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBNb24sIDggQXByIDIwMTkgMTM6MTY6MzggLTA0MDAKU3ViamVjdDogW1BBVENIIHYxXSBM ZXQgZGVidWdnZXIgaGFuZGxlIHByb2Nlc3Mgc3Bhd24gZXJyb3JzIG9uIHczMgogKEJ1ZyMzMzAx NikKCldoZW4gYW4gZXJyb3IgaXMgc2lnbmFsZWQgYmV0d2VlbiBibG9ja19pbnB1dCgpLi4udW5i bG9ja19pbnB1dCgpLCB0aGUKTGlzcCBkZWJ1Z2dlciBpcyBwcmV2ZW50ZWQgZnJvbSBzdGFydGlu Zy4KKiBzcmMvY2FsbHByb2MuYyAoY2hpbGRfc2V0dXApOiBNb3ZlIHRoZSByZXBvcnRfZmlsZV9l cnJvciBjYWxsIGZyb20gaGVyZS4uLgoqIHNyYy9wcm9jZXNzLmMgKGNyZWF0ZV9wcm9jZXNzKSBb V0lORE9XU05UXTogLi4uIHRvIGhlcmUsIGFmdGVyIHRoZQp1bmJsb2NrX2lucHV0KCkgY2FsbC4K LS0tCiBzcmMvY2FsbHByb2MuYyB8IDcgKystLS0tLQogc3JjL2xpc3AuaCAgICAgfCA2ICsrKysr Kwogc3JjL3Byb2Nlc3MuYyAgfCAyICstCiAzIGZpbGVzIGNoYW5nZWQsIDkgaW5zZXJ0aW9ucygr KSwgNiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvY2FsbHByb2MuYyBiL3NyYy9jYWxs cHJvYy5jCmluZGV4IGZhMTJkMDIuLmEwMTEyNTAgMTAwNjQ0Ci0tLSBhL3NyYy9jYWxscHJvYy5j CisrKyBiL3NyYy9jYWxscHJvYy5jCkBAIC02OTUsNyArNjk1LDcgQEAgY2FsbF9wcm9jZXNzIChw dHJkaWZmX3QgbmFyZ3MsIExpc3BfT2JqZWN0ICphcmdzLCBpbnQgZmlsZWZkLAogICB1bmJsb2Nr X2lucHV0ICgpOwogCiAgIGlmIChwaWQgPCAwKQotICAgIHJlcG9ydF9maWxlX2Vycm5vICgiRG9p bmcgdmZvcmsiLCBRbmlsLCBjaGlsZF9lcnJubyk7CisgICAgcmVwb3J0X2ZpbGVfZXJybm8gKENI SUxEX1NFVFVQX0VSUk9SX0RFU0MsIFFuaWwsIGNoaWxkX2Vycm5vKTsKIAogICAvKiBDbG9zZSBv dXIgZmlsZSBkZXNjcmlwdG9ycywgZXhjZXB0IGZvciBjYWxscHJvY19mZFtDQUxMUFJPQ19QSVBF UkVBRF0KICAgICAgc2luY2Ugd2Ugd2lsbCB1c2UgdGhhdCB0byByZWFkIGlucHV0IGZyb20uICAq LwpAQCAtMTE4OSw3ICsxMTg5LDcgQEAgZXhlY19mYWlsZWQgKGNoYXIgY29uc3QgKm5hbWUsIGlu dCBlcnIpCiAgICBleGVjdXRhYmxlIGRpcmVjdG9yeSBieSB0aGUgcGFyZW50LgogCiAgICBPbiBH TlVpc2ggaG9zdHMsIGVpdGhlciBleGVjIG9yIHJldHVybiBhbiBlcnJvciBudW1iZXIuCi0gICBP biBNUy1XaW5kb3dzLCBlaXRoZXIgcmV0dXJuIGEgcGlkIG9yIHNpZ25hbCBhbiBlcnJvci4KKyAg IE9uIE1TLVdpbmRvd3MsIGVpdGhlciByZXR1cm4gYSBwaWQgb3IgcmV0dXJuIC0xIGFuZCBzZXQg ZXJybm8uCiAgICBPbiBNUy1ET1MsIGVpdGhlciByZXR1cm4gYW4gZXhpdCBzdGF0dXMgb3Igc2ln bmFsIGFuIGVycm9yLiAgKi8KIAogQ0hJTERfU0VUVVBfVFlQRQpAQCAtMTMzNCw5ICsxMzM0LDYg QEAgY2hpbGRfc2V0dXAgKGludCBpbiwgaW50IG91dCwgaW50IGVyciwgY2hhciAqKm5ld19hcmd2 LCBib29sIHNldF9wZ3JwLAogICAvKiBTcGF3biB0aGUgY2hpbGQuICAoU2VlIHczMnByb2MuYzpz eXNfc3Bhd252ZSkuICAqLwogICBjcGlkID0gc3Bhd252ZSAoX1BfTk9XQUlULCBuZXdfYXJndlsw XSwgbmV3X2FyZ3YsIGVudik7CiAgIHJlc2V0X3N0YW5kYXJkX2hhbmRsZXMgKGluLCBvdXQsIGVy ciwgaGFuZGxlcyk7Ci0gIGlmIChjcGlkID09IC0xKQotICAgIC8qIEFuIGVycm9yIG9jY3VycmVk IHdoaWxlIHRyeWluZyB0byBzcGF3biB0aGUgcHJvY2Vzcy4gICovCi0gICAgcmVwb3J0X2ZpbGVf ZXJyb3IgKCJTcGF3bmluZyBjaGlsZCBwcm9jZXNzIiwgUW5pbCk7CiAgIHJldHVybiBjcGlkOwog CiAjZWxzZSAgLyogbm90IFdJTkRPV1NOVCAqLwpkaWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3Ny Yy9saXNwLmgKaW5kZXggMDhjNmRiZC4uYzdlYjQ3MSAxMDA2NDQKLS0tIGEvc3JjL2xpc3AuaAor KysgYi9zcmMvbGlzcC5oCkBAIC00MjMzLDYgKzQyMzMsMTIgQEAgZXh0ZXJuIHZvaWQgc2V0dXBf cHJvY2Vzc19jb2Rpbmdfc3lzdGVtcyAoTGlzcF9PYmplY3QpOwogI2Vsc2UKICMgZGVmaW5lIENI SUxEX1NFVFVQX1RZUEUgaW50CiAjZW5kaWYKKyNpZmRlZiBXSU5ET1dTTlQKKyMgZGVmaW5lIENI SUxEX1NFVFVQX0VSUk9SX0RFU0MgIlNwYXduaW5nIGNoaWxkIHByb2Nlc3MiCisjZWxzZQorIyBk ZWZpbmUgQ0hJTERfU0VUVVBfRVJST1JfREVTQyAiRG9pbmcgdmZvcmsiCisjZW5kaWYKKwogZXh0 ZXJuIENISUxEX1NFVFVQX1RZUEUgY2hpbGRfc2V0dXAgKGludCwgaW50LCBpbnQsIGNoYXIgKios IGJvb2wsIExpc3BfT2JqZWN0KTsKIGV4dGVybiB2b2lkIGluaXRfY2FsbHByb2NfMSAodm9pZCk7 CiBleHRlcm4gdm9pZCBpbml0X2NhbGxwcm9jICh2b2lkKTsKZGlmZiAtLWdpdCBhL3NyYy9wcm9j ZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4IDJkZjUxY2YuLmI4YjdhM2UgMTAwNjQ0Ci0tLSBh L3NyYy9wcm9jZXNzLmMKKysrIGIvc3JjL3Byb2Nlc3MuYwpAQCAtMjIwNCw3ICsyMjA0LDcgQEAg Y3JlYXRlX3Byb2Nlc3MgKExpc3BfT2JqZWN0IHByb2Nlc3MsIGNoYXIgKipuZXdfYXJndiwgTGlz cF9PYmplY3QgY3VycmVudF9kaXIpCiAgIHVuYmxvY2tfaW5wdXQgKCk7CiAKICAgaWYgKHBpZCA8 IDApCi0gICAgcmVwb3J0X2ZpbGVfZXJybm8gKCJEb2luZyB2Zm9yayIsIFFuaWwsIHZmb3JrX2Vy cm5vKTsKKyAgICByZXBvcnRfZmlsZV9lcnJubyAoQ0hJTERfU0VUVVBfRVJST1JfREVTQywgUW5p bCwgdmZvcmtfZXJybm8pOwogICBlbHNlCiAgICAgewogICAgICAgLyogdmZvcmsgc3VjY2VlZGVk LiAgKi8KLS0gCjIuNi4yLndpbmRvd3MuMQoK --000000000000a10e360586091718-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 14:59:20 2019 Received: (at 33016) by debbugs.gnu.org; 8 Apr 2019 18:59:20 +0000 Received: from localhost ([127.0.0.1]:50183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDZUG-0002uP-2y for submit@debbugs.gnu.org; Mon, 08 Apr 2019 14:59:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDZUD-0002uA-VD for 33016@debbugs.gnu.org; Mon, 08 Apr 2019 14:59:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDZU8-0003os-Dj; Mon, 08 Apr 2019 14:59:12 -0400 Received: from [176.228.60.248] (port=2931 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDZU5-0006kJ-QU; Mon, 08 Apr 2019 14:59:11 -0400 Date: Mon, 08 Apr 2019 21:58:58 +0300 Message-Id: <83y34k728d.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Mon, 8 Apr 2019 14:34:41 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Noam Postavsky > Date: Mon, 8 Apr 2019 14:34:41 -0400 > Cc: 33016@debbugs.gnu.org > > > M-x eval-expression RET > > (make-process :name "test" :command '("c:/No Such Command")) > > > > will merely display in the echo-area message: > > > > eval: Spawning child process: Invalid argument > > The confusing thing here is that the error is signaled between > block_input()...unblock_input(), which prevents the debugger from > triggering. E.g., the "-unless-debug" part in the expression below > appears not to work, even though the error flows normally in other > respects: > > (condition-case-unless-debug err > (make-process :name "test" :command '("c:/No Such Command")) > (error (list :error err))) > ;=> (:error (file-error "Spawning child process" "Invalid argument")) > > The attached patch fixes this by moving the signal to after the unblock_input(). Thanks, but could we have a test for this, please? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 09 10:14:19 2019 Received: (at 33016) by debbugs.gnu.org; 9 Apr 2019 14:14:19 +0000 Received: from localhost ([127.0.0.1]:51812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDrVy-0002hE-Vr for submit@debbugs.gnu.org; Tue, 09 Apr 2019 10:14:19 -0400 Received: from mail-oi1-f177.google.com ([209.85.167.177]:43001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDrVw-0002gw-CC for 33016@debbugs.gnu.org; Tue, 09 Apr 2019 10:14:16 -0400 Received: by mail-oi1-f177.google.com with SMTP id w139so13626311oie.9 for <33016@debbugs.gnu.org>; Tue, 09 Apr 2019 07:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bj/9Soz6z+HLXjLELv7LepKqPpBvMOH6fKyBZXVTe5Y=; b=BgagIx+yF6sTdXom8ndTijb5wruvRFHlPuoAmgBESdqBeR3+k0xyIevP1Z+yO0s4Go nh+kmmDADU7bQxADTmPwAXR0+uwhs1Ny5x7h3zj0U51tc/G3PW/XW/+8JsYC4MCBDM9U 3PsHLzH7jdZ/j4j7ly28pD6BM85Pv2MOO7nCMOfzzvfYaEsOTjtZTNlzh3WV6mv6SGgJ e2bmxIlM4tc8xWG/03Ln4svjg0enAXxengrRTD6d8r4hOmcsaWXUjrFqWKoSA3RzZHOh 7q9Yf3Js3vQqpgBwX4Km1dJizsEkPI74jpt9SzVoB0ze1LhzuA4KmCzKzlqWAjQ9dmEH 16Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bj/9Soz6z+HLXjLELv7LepKqPpBvMOH6fKyBZXVTe5Y=; b=P2It/5QDABN3TuNg1zDQLqyK+UD6cFJF1LBe3AghyrcO1xRQ0njNlgOw7xWp7iC+hM qBX+cW+pbs13vhZIGJTFw773HU+1tdAr70czAOO29N9CK8YaqLFWpkTwucdT31QK5iJq RW8xetJlEUwHusbUqMw8SgQp+dSpz5+mo28o7tjQtVvku9UsbiqqYB28ZmpBHJbuu5mj 6NqQIaHJW8y8JBXNyv0zlz2+/sPBB3eZDDxaZdqE0A5/ZGCv2OV/oPbz3U1AolhTkPct YXRSHnAr7OG15C9SXVkRdsmRy72iDswQeyoWcjr7qoJRgEbxvjX+XK36i2SjKlq97urG /Q+Q== X-Gm-Message-State: APjAAAXDyfUjprFuHnbOBQxhIrbnY0xdAp8hL3PkQBWiw8B6ViTUoFc+ jY/qXs9PlbH5y5Xwu8zIhz/sx4CLnm9F1hG3g6s= X-Google-Smtp-Source: APXvYqyrTgc8y8RtQofoptcku/ze+GfCSXoVOfG0w5MJhs3sfdp8GTGlOBws53Mi28VJUGPCOU8Yd3j4jn2fsvt5xdA= X-Received: by 2002:aca:bf08:: with SMTP id p8mr18828567oif.173.1554819250557; Tue, 09 Apr 2019 07:14:10 -0700 (PDT) MIME-Version: 1.0 References: <83y34k728d.fsf@gnu.org> In-Reply-To: <83y34k728d.fsf@gnu.org> From: Noam Postavsky Date: Tue, 9 Apr 2019 10:13:58 -0400 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000001eea3d0586199186" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001eea3d0586199186 Content-Type: text/plain; charset="UTF-8" On Mon, 8 Apr 2019 at 14:59, Eli Zaretskii wrote: > > The confusing thing here is that the error is signaled between > > block_input()...unblock_input(), which prevents the debugger from > > triggering. > > The attached patch fixes this by moving the signal to after the unblock_input(). > > Thanks, but could we have a test for this, please? Yes (I had initially thought it wouldn't work because of the way ert uses the debugger internally, but it actually turns out fine). By the way, I modified the error message in call_process in addition to create_process for completeness, 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. --0000000000001eea3d0586199186 Content-Type: application/octet-stream; name="v2-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Disposition: attachment; filename="v2-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ju9v47zb0 RnJvbSBkNzc2MmYyNTk5Y2JkMmZlZDFiNjYxYjYwZGFjZjZmZDQ0NGE3ZjM5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBNb24sIDggQXByIDIwMTkgMTc6NTc6MjIgLTA0MDAKU3ViamVjdDogW1BBVENIIHYyXSBM ZXQgZGVidWdnZXIgaGFuZGxlIHByb2Nlc3Mgc3Bhd24gZXJyb3JzIG9uIHczMgogKEJ1ZyMzMzAx NikKClNpbmNlIGNoaWxkX3NldHVwKCkgaXMgY2FsbGVkIGJldHdlZW4gYmxvY2tfaW5wdXQoKS4u LnVuYmxvY2tfaW5wdXQoKSwKd2hlbiBhbiBlcnJvciBpcyBzaWduYWxlZCB0aGUgTGlzcCBkZWJ1 Z2dlciBpcyBwcmV2ZW50ZWQgZnJvbQpzdGFydGluZy4gIFRoZXJlZm9yZSwgbGV0IHRoZSBjYWxs ZXJzIHNpZ25hbCB0aGUgZXJyb3IgaW5zdGVhZCAod2hpY2gKdGhleSBhbHJlYWR5IGRvIGZvciBu b24tdzMyIHBsYXRmb3JtcywganVzdCB0aGUgZXJyb3IgbWVzc2FnZSBuZWVkcyBhbgp1cGRhdGUp LgoqIHNyYy9jYWxscHJvYy5jIChjaGlsZF9zZXR1cCkgW1dJTkRPV1NOVF06IERvbid0IGNhbGwK cmVwb3J0X2ZpbGVfZXJyb3IgaGVyZS4KKGNhbGxfcHJvY2VzcykgW1dJTkRPV05UXToKKiBzcmMv cHJvY2Vzcy5jIChjcmVhdGVfcHJvY2VzcykgW1dJTkRPV1NOVF06IENhbGwgcmVwb3J0X2ZpbGVf ZXJybm8KaGVyZSBpbnN0ZWFkLCBhZnRlciB0aGUgdW5ibG9ja19pbnB1dCgpIGNhbGwsIHNhbWUg YXMgZm9yICFXSU5ET1dTTlQuCiogc3JjL2xpc3AuaCAoQ0hJTERfU0VUVVBfRVJST1JfREVTQyk6 IE5ldyBwcmVwcm9jZXNzb3IgZGVmaW5lLgoqIHRlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwgKG1h a2UtcHJvY2Vzcy13MzItc3Bhd24tbm9uZXhpc3RlbnQpOiBOZXcKdGVzdC4KLS0tCiBzcmMvY2Fs bHByb2MuYyAgICAgICAgICAgIHwgIDcgKystLS0tLQogc3JjL2xpc3AuaCAgICAgICAgICAgICAg ICB8ICA2ICsrKysrKwogc3JjL3Byb2Nlc3MuYyAgICAgICAgICAgICB8ICAyICstCiB0ZXN0L3Ny Yy9wcm9jZXNzLXRlc3RzLmVsIHwgMTIgKysrKysrKysrKysrCiA0IGZpbGVzIGNoYW5nZWQsIDIx IGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2NhbGxwcm9j LmMgYi9zcmMvY2FsbHByb2MuYwppbmRleCBhM2QwOTYwLi4yY2RmODRkIDEwMDY0NAotLS0gYS9z cmMvY2FsbHByb2MuYworKysgYi9zcmMvY2FsbHByb2MuYwpAQCAtNjgxLDcgKzY4MSw3IEBAIGNh bGxfcHJvY2VzcyAocHRyZGlmZl90IG5hcmdzLCBMaXNwX09iamVjdCAqYXJncywgaW50IGZpbGVm ZCwKICAgdW5ibG9ja19pbnB1dCAoKTsKIAogICBpZiAocGlkIDwgMCkKLSAgICByZXBvcnRfZmls ZV9lcnJubyAoIkRvaW5nIHZmb3JrIiwgUW5pbCwgY2hpbGRfZXJybm8pOworICAgIHJlcG9ydF9m aWxlX2Vycm5vIChDSElMRF9TRVRVUF9FUlJPUl9ERVNDLCBRbmlsLCBjaGlsZF9lcnJubyk7CiAK ICAgLyogQ2xvc2Ugb3VyIGZpbGUgZGVzY3JpcHRvcnMsIGV4Y2VwdCBmb3IgY2FsbHByb2NfZmRb Q0FMTFBST0NfUElQRVJFQURdCiAgICAgIHNpbmNlIHdlIHdpbGwgdXNlIHRoYXQgdG8gcmVhZCBp bnB1dCBmcm9tLiAgKi8KQEAgLTExNzQsNyArMTE3NCw3IEBAIGV4ZWNfZmFpbGVkIChjaGFyIGNv bnN0ICpuYW1lLCBpbnQgZXJyKQogICAgZXhlY3V0YWJsZSBkaXJlY3RvcnkgYnkgdGhlIHBhcmVu dC4KIAogICAgT24gR05VaXNoIGhvc3RzLCBlaXRoZXIgZXhlYyBvciByZXR1cm4gYW4gZXJyb3Ig bnVtYmVyLgotICAgT24gTVMtV2luZG93cywgZWl0aGVyIHJldHVybiBhIHBpZCBvciBzaWduYWwg YW4gZXJyb3IuCisgICBPbiBNUy1XaW5kb3dzLCBlaXRoZXIgcmV0dXJuIGEgcGlkIG9yIHJldHVy biAtMSBhbmQgc2V0IGVycm5vLgogICAgT24gTVMtRE9TLCBlaXRoZXIgcmV0dXJuIGFuIGV4aXQg c3RhdHVzIG9yIHNpZ25hbCBhbiBlcnJvci4gICovCiAKIENISUxEX1NFVFVQX1RZUEUKQEAgLTEz MTksOSArMTMxOSw2IEBAIGNoaWxkX3NldHVwIChpbnQgaW4sIGludCBvdXQsIGludCBlcnIsIGNo YXIgKipuZXdfYXJndiwgYm9vbCBzZXRfcGdycCwKICAgLyogU3Bhd24gdGhlIGNoaWxkLiAgKFNl ZSB3MzJwcm9jLmM6c3lzX3NwYXdudmUpLiAgKi8KICAgY3BpZCA9IHNwYXdudmUgKF9QX05PV0FJ VCwgbmV3X2FyZ3ZbMF0sIG5ld19hcmd2LCBlbnYpOwogICByZXNldF9zdGFuZGFyZF9oYW5kbGVz IChpbiwgb3V0LCBlcnIsIGhhbmRsZXMpOwotICBpZiAoY3BpZCA9PSAtMSkKLSAgICAvKiBBbiBl cnJvciBvY2N1cnJlZCB3aGlsZSB0cnlpbmcgdG8gc3Bhd24gdGhlIHByb2Nlc3MuICAqLwotICAg IHJlcG9ydF9maWxlX2Vycm9yICgiU3Bhd25pbmcgY2hpbGQgcHJvY2VzcyIsIFFuaWwpOwogICBy ZXR1cm4gY3BpZDsKIAogI2Vsc2UgIC8qIG5vdCBXSU5ET1dTTlQgKi8KZGlmZiAtLWdpdCBhL3Ny Yy9saXNwLmggYi9zcmMvbGlzcC5oCmluZGV4IGEwYTdjYmQuLjZmMzkyNjUgMTAwNjQ0Ci0tLSBh L3NyYy9saXNwLmgKKysrIGIvc3JjL2xpc3AuaApAQCAtNDQ3Nyw2ICs0NDc3LDEyIEBAIGV4dGVy biB2b2lkIHNldHVwX3Byb2Nlc3NfY29kaW5nX3N5c3RlbXMgKExpc3BfT2JqZWN0KTsKICNlbHNl CiAjIGRlZmluZSBDSElMRF9TRVRVUF9UWVBFIGludAogI2VuZGlmCisjaWZkZWYgV0lORE9XU05U CisjIGRlZmluZSBDSElMRF9TRVRVUF9FUlJPUl9ERVNDICJTcGF3bmluZyBjaGlsZCBwcm9jZXNz IgorI2Vsc2UKKyMgZGVmaW5lIENISUxEX1NFVFVQX0VSUk9SX0RFU0MgIkRvaW5nIHZmb3JrIgor I2VuZGlmCisKIGV4dGVybiBDSElMRF9TRVRVUF9UWVBFIGNoaWxkX3NldHVwIChpbnQsIGludCwg aW50LCBjaGFyICoqLCBib29sLCBMaXNwX09iamVjdCk7CiBleHRlcm4gdm9pZCBpbml0X2NhbGxw cm9jXzEgKHZvaWQpOwogZXh0ZXJuIHZvaWQgaW5pdF9jYWxscHJvYyAodm9pZCk7CmRpZmYgLS1n aXQgYS9zcmMvcHJvY2Vzcy5jIGIvc3JjL3Byb2Nlc3MuYwppbmRleCA4MDJhYzAyLi5mZjA4NjU3 IDEwMDY0NAotLS0gYS9zcmMvcHJvY2Vzcy5jCisrKyBiL3NyYy9wcm9jZXNzLmMKQEAgLTIyMzIs NyArMjIzMiw3IEBAIGNyZWF0ZV9wcm9jZXNzIChMaXNwX09iamVjdCBwcm9jZXNzLCBjaGFyICoq bmV3X2FyZ3YsIExpc3BfT2JqZWN0IGN1cnJlbnRfZGlyKQogICB1bmJsb2NrX2lucHV0ICgpOwog CiAgIGlmIChwaWQgPCAwKQotICAgIHJlcG9ydF9maWxlX2Vycm5vICgiRG9pbmcgdmZvcmsiLCBR bmlsLCB2Zm9ya19lcnJubyk7CisgICAgcmVwb3J0X2ZpbGVfZXJybm8gKENISUxEX1NFVFVQX0VS Uk9SX0RFU0MsIFFuaWwsIHZmb3JrX2Vycm5vKTsKICAgZWxzZQogICAgIHsKICAgICAgIC8qIHZm b3JrIHN1Y2NlZWRlZC4gICovCmRpZmYgLS1naXQgYS90ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVs IGIvdGVzdC9zcmMvcHJvY2Vzcy10ZXN0cy5lbAppbmRleCA1ZGJmNDQxLi43Nzk2NjVhZCAxMDA2 NDQKLS0tIGEvdGVzdC9zcmMvcHJvY2Vzcy10ZXN0cy5lbAorKysgYi90ZXN0L3NyYy9wcm9jZXNz LXRlc3RzLmVsCkBAIC0yMTUsNiArMjE1LDE4IEBAIHByb2Nlc3MtdGVzdHMtLW1peGFibGUKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmluZy10by1saXN0ICJzdGRv dXRcbiIpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmctdG8t bGlzdCAic3RkZXJyXG4iKSkpKSkpCiAKKyhlcnQtZGVmdGVzdCBtYWtlLXByb2Nlc3MtdzMyLXNw YXduLW5vbmV4aXN0ZW50ICgpCisgICJDaGVjayB0aGF0IGRlYnVnZ2VyIHJ1bnMgb24gYG1ha2Ut cHJvY2VzcycgZmFpbHVyZSAoQnVnIzMzMDE2KS4iCisgIChza2lwLXVubGVzcyAoZXEgc3lzdGVt LXR5cGUgJ3dpbmRvd3MtbnQpKQorICAobGV0KiAoKGRlYnVnLW9uLWVycm9yIHQpCisgICAgICAg ICAoaGF2ZS1jYWxsZWQtZGVidWdnZXIgbmlsKQorICAgICAgICAgKGRlYnVnZ2VyIChsYW1iZGEg KCZyZXN0IF8pIChzZXRxIGhhdmUtY2FsbGVkLWRlYnVnZ2VyIHQpKSkpCisgICAgKHNob3VsZCAo ZXEgOmdvdC1lcnJvciA7OyBOT1RFOiBgc2hvdWxkLWVycm9yJyB3b3VsZCBpbmhpYml0IGRlYnVn Z2VyLgorICAgICAgICAgICAgICAgIChjb25kaXRpb24tY2FzZS11bmxlc3MtZGVidWcgKCkKKyAg ICAgICAgICAgICAgICAgICAgKG1ha2UtcHJvY2VzcyA6bmFtZSAidGVzdCIgOmNvbW1hbmQgJygi YzovTm8tU3VjaC1Db21tYW5kIikpCisgICAgICAgICAgICAgICAgICAoZXJyb3IgOmdvdC1lcnJv cikpKSkKKyAgICAoc2hvdWxkIGhhdmUtY2FsbGVkLWRlYnVnZ2VyKSkpCisKIChlcnQtZGVmdGVz dCBtYWtlLXByb2Nlc3MvZmlsZS1oYW5kbGVyL2ZvdW5kICgpCiAgICJDaGVjayB0aGF0IHRoZSDi gJg6ZmlsZS1oYW5kbGVy4oCZIGFyZ3VtZW50IG9mIOKAmG1ha2UtcHJvY2Vzc+KAmQogd29ya3Mg YXMgZXhwZWN0ZWQgaWYgYSBmaWxlIG5hbWUgaGFuZGxlciBpcyBmb3VuZC4iCi0tIAoyLjYuMi53 aW5kb3dzLjEKCg== --0000000000001eea3d0586199186-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 09 10:33:28 2019 Received: (at 33016) by debbugs.gnu.org; 9 Apr 2019 14:33:29 +0000 Received: from localhost ([127.0.0.1]:51832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDroW-0003HS-KL for submit@debbugs.gnu.org; Tue, 09 Apr 2019 10:33:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDroU-0003HC-VN for 33016@debbugs.gnu.org; Tue, 09 Apr 2019 10:33:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDroP-00013d-Mu; Tue, 09 Apr 2019 10:33:21 -0400 Received: from [176.228.60.248] (port=4218 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDroP-0000My-6L; Tue, 09 Apr 2019 10:33:21 -0400 Date: Tue, 09 Apr 2019 17:33:18 +0300 Message-Id: <83bm1f6yfl.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Tue, 9 Apr 2019 10:13:58 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Noam Postavsky > Date: Tue, 9 Apr 2019 10:13:58 -0400 > Cc: Klaus-Dieter Bauer , 33016@debbugs.gnu.org > > By the way, I modified the error message in call_process in addition > to create_process for completeness, 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. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 10 17:59:01 2019 Received: (at 33016) by debbugs.gnu.org; 10 Apr 2019 21:59:01 +0000 Received: from localhost ([127.0.0.1]:53634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hELFF-0004LD-Bp for submit@debbugs.gnu.org; Wed, 10 Apr 2019 17:59:01 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:43352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hELFD-0004L0-Hv for 33016@debbugs.gnu.org; Wed, 10 Apr 2019 17:59:00 -0400 Received: by mail-oi1-f169.google.com with SMTP id t81so3141698oig.10 for <33016@debbugs.gnu.org>; Wed, 10 Apr 2019 14:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5MBprG12DcKBIhP5mLgGrB1lBoHStsW34DgXU+RMWg=; b=GnFGjEDD0I4THWKAN/eybXFgjNN5rfc/rCEEANhlj2fE0bQ/C/R3W40CHou43xCJAw AlE5NPmbKT/1h9aeW7JetLugcYTK0JPlkVIPxgELBtVCFJGQy3ZYv6ISGz9SUb36DlOo 19zY3cdX95wx3uAveKuC0yUdcCvcDrB7P0iBxTvKIB3Amcst7pVJo0YSerGIJIJ2+Rd8 vPTUx5v1ZUvpnFej60GN8TaDQKDJrfwycjzfI5gjvK8m5122VQqpt7I98t08B8AF9Ha2 58nvycJP/DNJzRhwkJkylsJ44dY+Uvgc6LzEPsXv/zxXSFskRTlMdVCDxKYgOeH0HUGf V9VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5MBprG12DcKBIhP5mLgGrB1lBoHStsW34DgXU+RMWg=; b=eH03BzLLgi5z7hFuEOAoSTm9I/TZSJ+ANL+6TcNS75n5TBHrf5S0Xo0BeODGKZKgIp F43VbxUkt9cjEuKpR0rMNziHuIC+0Qvx8QuONf8aXEkQio3Kj2Vswj5p+9v3UGbaLh4k KlZ8fXGvaWDYW7G4FN1wh1qvJ41dlIX7hX9XguC94rTg4C4o5nU4vPLnfFRb/8viTpjr qe+1KXR7ibd2fkylkMyNdKTNT815shzy3PtT618BhUKS933+Xvi5v4CNa68hc7QQv5J0 fS/EHTY+AMrWG8Xlf9T3SCijRzac7FIEggXyOkxZVWs/l5nVTPWREyOWoleEKYyUSEBi 6+XQ== X-Gm-Message-State: APjAAAWIzc1Y7yR8YHU7vyfQA62sj9zcTL6um6Ueuh+8M8sDI95rxUfe zJnA33a5Ng7F7NKPojeI7Hkf2Qg9oFCC6+RjF3A= X-Google-Smtp-Source: APXvYqzAkU4fDw+anu1HWOwJPtpy0k8y3FdLZScEPkFAKlwxYU/dgMVFeyu0MCJEXS4QQe1j1PAgh/BOQWaK/2upRFo= X-Received: by 2002:aca:ac84:: with SMTP id v126mr3929762oie.87.1554933533680; Wed, 10 Apr 2019 14:58:53 -0700 (PDT) MIME-Version: 1.0 References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> In-Reply-To: <83bm1f6yfl.fsf@gnu.org> From: Noam Postavsky Date: Wed, 10 Apr 2019 17:58:43 -0400 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Eli Zaretskii Content-Type: multipart/mixed; boundary="000000000000ecc7410586342caf" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ecc7410586342caf Content-Type: text/plain; charset="UTF-8" On Tue, 9 Apr 2019 at 10:33, Eli Zaretskii 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?). --000000000000ecc7410586342caf Content-Type: application/x-patch; name="v3-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Disposition: attachment; filename="v3-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jubf25wf0 RnJvbSA5OTg4Mzg3YTg3ZjFiZjNhOGFkM2RmYWM1MzZjNmEyNmJiOTVkNDFiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBNb24sIDggQXByIDIwMTkgMTc6NTc6MjIgLTA0MDAKU3ViamVjdDogW1BBVENIIHYzXSBM ZXQgZGVidWdnZXIgaGFuZGxlIHByb2Nlc3Mgc3Bhd24gZXJyb3JzIG9uIHczMgogKEJ1ZyMzMzAx NikKClNpbmNlIGNoaWxkX3NldHVwKCkgaXMgY2FsbGVkIGJldHdlZW4gYmxvY2tfaW5wdXQoKS4u LnVuYmxvY2tfaW5wdXQoKSwKd2hlbiBhbiBlcnJvciBpcyBzaWduYWxlZCB0aGUgTGlzcCBkZWJ1 Z2dlciBpcyBwcmV2ZW50ZWQgZnJvbQpzdGFydGluZy4gIFRoZXJlZm9yZSwgbGV0IHRoZSBjYWxs ZXJzIHNpZ25hbCB0aGUgZXJyb3IgaW5zdGVhZCAod2hpY2gKdGhleSBhbHJlYWR5IGRvIGZvciBu b24tdzMyIHBsYXRmb3JtcywganVzdCB0aGUgZXJyb3IgbWVzc2FnZSBuZWVkcyBhbgp1cGRhdGUp LgoqIHNyYy9jYWxscHJvYy5jIChjaGlsZF9zZXR1cCkgW1dJTkRPV1NOVF06IERvbid0IGNhbGwK cmVwb3J0X2ZpbGVfZXJyb3IgaGVyZS4KKGNhbGxfcHJvY2VzcykgW1dJTkRPV05UXToKKiBzcmMv cHJvY2Vzcy5jIChjcmVhdGVfcHJvY2VzcykgW1dJTkRPV1NOVF06IENhbGwgcmVwb3J0X2ZpbGVf ZXJybm8KaGVyZSBpbnN0ZWFkLCBhZnRlciB0aGUgdW5ibG9ja19pbnB1dCgpIGNhbGwsIHNhbWUg YXMgZm9yICFXSU5ET1dTTlQuCiogc3JjL2xpc3AuaCAoQ0hJTERfU0VUVVBfRVJST1JfREVTQyk6 IE5ldyBwcmVwcm9jZXNzb3IgZGVmaW5lLiAgRmxpcAp0aGUgY29udGFpbmluZyBpZm5kZWYgRE9T X05UIGJyYW5jaGVzIHNvIHRoYXQgaXQncyBpZmRlZiBET1NfTlQuCiogdGVzdC9zcmMvcHJvY2Vz cy10ZXN0cy5lbCAobWFrZS1wcm9jZXNzLXczMi1kZWJ1Zy1zcGF3bi1lcnJvcik6CiogdGVzdC9z cmMvY2FsbHByb2MtdGVzdHMuZWwgKGNhbGwtcHJvY2Vzcy13MzItZGVidWctc3Bhd24tZXJyb3Ip OiBOZXcKdGVzdHMuCi0tLQogc3JjL2NhbGxwcm9jLmMgICAgICAgICAgICAgfCAgNyArKy0tLS0t CiBzcmMvbGlzcC5oICAgICAgICAgICAgICAgICB8ICA5ICsrKysrKy0tLQogc3JjL3Byb2Nlc3Mu YyAgICAgICAgICAgICAgfCAgMiArLQogdGVzdC9zcmMvY2FsbHByb2MtdGVzdHMuZWwgfCAxNiAr KysrKysrKysrKysrKysrCiB0ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVsICB8IDE1ICsrKysrKysr KysrKysrKwogNSBmaWxlcyBjaGFuZ2VkLCA0MCBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygt KQoKZGlmZiAtLWdpdCBhL3NyYy9jYWxscHJvYy5jIGIvc3JjL2NhbGxwcm9jLmMKaW5kZXggYTNk MDk2MC4uMmNkZjg0ZCAxMDA2NDQKLS0tIGEvc3JjL2NhbGxwcm9jLmMKKysrIGIvc3JjL2NhbGxw cm9jLmMKQEAgLTY4MSw3ICs2ODEsNyBAQCBjYWxsX3Byb2Nlc3MgKHB0cmRpZmZfdCBuYXJncywg TGlzcF9PYmplY3QgKmFyZ3MsIGludCBmaWxlZmQsCiAgIHVuYmxvY2tfaW5wdXQgKCk7CiAKICAg aWYgKHBpZCA8IDApCi0gICAgcmVwb3J0X2ZpbGVfZXJybm8gKCJEb2luZyB2Zm9yayIsIFFuaWws IGNoaWxkX2Vycm5vKTsKKyAgICByZXBvcnRfZmlsZV9lcnJubyAoQ0hJTERfU0VUVVBfRVJST1Jf REVTQywgUW5pbCwgY2hpbGRfZXJybm8pOwogCiAgIC8qIENsb3NlIG91ciBmaWxlIGRlc2NyaXB0 b3JzLCBleGNlcHQgZm9yIGNhbGxwcm9jX2ZkW0NBTExQUk9DX1BJUEVSRUFEXQogICAgICBzaW5j ZSB3ZSB3aWxsIHVzZSB0aGF0IHRvIHJlYWQgaW5wdXQgZnJvbS4gICovCkBAIC0xMTc0LDcgKzEx NzQsNyBAQCBleGVjX2ZhaWxlZCAoY2hhciBjb25zdCAqbmFtZSwgaW50IGVycikKICAgIGV4ZWN1 dGFibGUgZGlyZWN0b3J5IGJ5IHRoZSBwYXJlbnQuCiAKICAgIE9uIEdOVWlzaCBob3N0cywgZWl0 aGVyIGV4ZWMgb3IgcmV0dXJuIGFuIGVycm9yIG51bWJlci4KLSAgIE9uIE1TLVdpbmRvd3MsIGVp dGhlciByZXR1cm4gYSBwaWQgb3Igc2lnbmFsIGFuIGVycm9yLgorICAgT24gTVMtV2luZG93cywg ZWl0aGVyIHJldHVybiBhIHBpZCBvciByZXR1cm4gLTEgYW5kIHNldCBlcnJuby4KICAgIE9uIE1T LURPUywgZWl0aGVyIHJldHVybiBhbiBleGl0IHN0YXR1cyBvciBzaWduYWwgYW4gZXJyb3IuICAq LwogCiBDSElMRF9TRVRVUF9UWVBFCkBAIC0xMzE5LDkgKzEzMTksNiBAQCBjaGlsZF9zZXR1cCAo aW50IGluLCBpbnQgb3V0LCBpbnQgZXJyLCBjaGFyICoqbmV3X2FyZ3YsIGJvb2wgc2V0X3BncnAs CiAgIC8qIFNwYXduIHRoZSBjaGlsZC4gIChTZWUgdzMycHJvYy5jOnN5c19zcGF3bnZlKS4gICov CiAgIGNwaWQgPSBzcGF3bnZlIChfUF9OT1dBSVQsIG5ld19hcmd2WzBdLCBuZXdfYXJndiwgZW52 KTsKICAgcmVzZXRfc3RhbmRhcmRfaGFuZGxlcyAoaW4sIG91dCwgZXJyLCBoYW5kbGVzKTsKLSAg aWYgKGNwaWQgPT0gLTEpCi0gICAgLyogQW4gZXJyb3Igb2NjdXJyZWQgd2hpbGUgdHJ5aW5nIHRv IHNwYXduIHRoZSBwcm9jZXNzLiAgKi8KLSAgICByZXBvcnRfZmlsZV9lcnJvciAoIlNwYXduaW5n IGNoaWxkIHByb2Nlc3MiLCBRbmlsKTsKICAgcmV0dXJuIGNwaWQ7CiAKICNlbHNlICAvKiBub3Qg V0lORE9XU05UICovCmRpZmYgLS1naXQgYS9zcmMvbGlzcC5oIGIvc3JjL2xpc3AuaAppbmRleCBh MGE3Y2JkLi40ZmUzMjM0IDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3NyYy9saXNwLmgK QEAgLTQ0NzIsMTEgKzQ0NzIsMTQgQEAgZXh0ZXJuIHZvaWQgc3ltc19vZl9wcm9jZXNzICh2b2lk KTsKIGV4dGVybiB2b2lkIHNldHVwX3Byb2Nlc3NfY29kaW5nX3N5c3RlbXMgKExpc3BfT2JqZWN0 KTsKIAogLyogRGVmaW5lZCBpbiBjYWxscHJvYy5jLiAgKi8KLSNpZm5kZWYgRE9TX05UCi0jIGRl ZmluZSBDSElMRF9TRVRVUF9UWVBFIF9Ob3JldHVybiB2b2lkCi0jZWxzZQorI2lmZGVmIERPU19O VAogIyBkZWZpbmUgQ0hJTERfU0VUVVBfVFlQRSBpbnQKKyMgZGVmaW5lIENISUxEX1NFVFVQX0VS Uk9SX0RFU0MgIlNwYXduaW5nIGNoaWxkIHByb2Nlc3MiCisjZWxzZQorIyBkZWZpbmUgQ0hJTERf U0VUVVBfVFlQRSBfTm9yZXR1cm4gdm9pZAorIyBkZWZpbmUgQ0hJTERfU0VUVVBfRVJST1JfREVT QyAiRG9pbmcgdmZvcmsiCiAjZW5kaWYKKwogZXh0ZXJuIENISUxEX1NFVFVQX1RZUEUgY2hpbGRf c2V0dXAgKGludCwgaW50LCBpbnQsIGNoYXIgKiosIGJvb2wsIExpc3BfT2JqZWN0KTsKIGV4dGVy biB2b2lkIGluaXRfY2FsbHByb2NfMSAodm9pZCk7CiBleHRlcm4gdm9pZCBpbml0X2NhbGxwcm9j ICh2b2lkKTsKZGlmZiAtLWdpdCBhL3NyYy9wcm9jZXNzLmMgYi9zcmMvcHJvY2Vzcy5jCmluZGV4 IDgwMmFjMDIuLmZmMDg2NTcgMTAwNjQ0Ci0tLSBhL3NyYy9wcm9jZXNzLmMKKysrIGIvc3JjL3By b2Nlc3MuYwpAQCAtMjIzMiw3ICsyMjMyLDcgQEAgY3JlYXRlX3Byb2Nlc3MgKExpc3BfT2JqZWN0 IHByb2Nlc3MsIGNoYXIgKipuZXdfYXJndiwgTGlzcF9PYmplY3QgY3VycmVudF9kaXIpCiAgIHVu YmxvY2tfaW5wdXQgKCk7CiAKICAgaWYgKHBpZCA8IDApCi0gICAgcmVwb3J0X2ZpbGVfZXJybm8g KCJEb2luZyB2Zm9yayIsIFFuaWwsIHZmb3JrX2Vycm5vKTsKKyAgICByZXBvcnRfZmlsZV9lcnJu byAoQ0hJTERfU0VUVVBfRVJST1JfREVTQywgUW5pbCwgdmZvcmtfZXJybm8pOwogICBlbHNlCiAg ICAgewogICAgICAgLyogdmZvcmsgc3VjY2VlZGVkLiAgKi8KZGlmZiAtLWdpdCBhL3Rlc3Qvc3Jj L2NhbGxwcm9jLXRlc3RzLmVsIGIvdGVzdC9zcmMvY2FsbHByb2MtdGVzdHMuZWwKaW5kZXggN2Iz MGEyNS4uYTI3MjhhMyAxMDA2NDQKLS0tIGEvdGVzdC9zcmMvY2FsbHByb2MtdGVzdHMuZWwKKysr IGIvdGVzdC9zcmMvY2FsbHByb2MtdGVzdHMuZWwKQEAgLTM3LDMgKzM3LDE5IEBACiAgICAgICAg IChzcGxpdC1zdHJpbmctYW5kLXVucXVvdGUgKGJ1ZmZlci1zdHJpbmcpKSkKICAgICAoc2hvdWxk IChlcXVhbCBpbml0aWFsLXNoZWxsICJuaWwiKSkKICAgICAoc2hvdWxkLW5vdCAoZXF1YWwgaW5p dGlhbC1zaGVsbCBzaGVsbCkpKSkKKworKGVydC1kZWZ0ZXN0IGNhbGwtcHJvY2Vzcy13MzItZGVi dWctc3Bhd24tZXJyb3IgKCkKKyAgIkNoZWNrIHRoYXQgZGVidWdnZXIgcnVucyBvbiBgY2FsbC1w cm9jZXNzJyBmYWlsdXJlIChCdWcjMzMwMTYpLiIKKyAgKHNraXAtdW5sZXNzIChlcSBzeXN0ZW0t dHlwZSAnd2luZG93cy1udCkpCisgIChsZXQqICgoZGVidWctb24tZXJyb3IgdCkKKyAgICAgICAg IChoYXZlLWNhbGxlZC1kZWJ1Z2dlciBuaWwpCisgICAgICAgICAoZGVidWdnZXIgKGxhbWJkYSAo JnJlc3QgXykgKHNldHEgaGF2ZS1jYWxsZWQtZGVidWdnZXIgdCkpKSkKKyAgICAoc2hvdWxkIChl cSA6Z290LWVycm9yIDs7IE5PVEU6IGBzaG91bGQtZXJyb3InIHdvdWxkIGluaGliaXQgZGVidWdn ZXIuCisgICAgICAgICAgICAgICAgKGNvbmRpdGlvbi1jYXNlLXVubGVzcy1kZWJ1ZyAoKQorICAg ICAgICAgICAgICAgICAgICA7OyBPbiBXaW5kb3dzLCAibnVsLkZPTyIgaXMgdGhlIGVtcHR5IGZp bGUgZm9yIGFueQorICAgICAgICAgICAgICAgICAgICA7OyBGT08sIGluIGFueSBkaXJlY3Rvcnku ICBTbyB0aGlzIHBhc3NlcyBFbWFjcycKKyAgICAgICAgICAgICAgICAgICAgOzsgdGVzdCBmb3Ig dGhlIGZpbGUncyBleGlzdGVuY2UsIGFuZCBlbnN1cmVzIHdlCisgICAgICAgICAgICAgICAgICAg IDs7IGhpdCBhbiBlcnJvciBpbiB0aGUgdzMyIHByb2Nlc3Mgc3Bhd24gY29kZS4KKyAgICAgICAg ICAgICAgICAgICAgKGNhbGwtcHJvY2VzcyAiYzovbnVsLmV4ZSIpCisgICAgICAgICAgICAgICAg ICAoZXJyb3IgOmdvdC1lcnJvcikpKSkKKyAgICAoc2hvdWxkIGhhdmUtY2FsbGVkLWRlYnVnZ2Vy KSkpCmRpZmYgLS1naXQgYS90ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVsIGIvdGVzdC9zcmMvcHJv Y2Vzcy10ZXN0cy5lbAppbmRleCA1ZGJmNDQxLi4yNWE1MmI3IDEwMDY0NAotLS0gYS90ZXN0L3Ny Yy9wcm9jZXNzLXRlc3RzLmVsCisrKyBiL3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwKQEAgLTIx NSw2ICsyMTUsMjEgQEAgcHJvY2Vzcy10ZXN0cy0tbWl4YWJsZQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoc3RyaW5nLXRvLWxpc3QgInN0ZG91dFxuIikKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmluZy10by1saXN0ICJzdGRlcnJcbiIp KSkpKSkKIAorKGVydC1kZWZ0ZXN0IG1ha2UtcHJvY2Vzcy13MzItZGVidWctc3Bhd24tZXJyb3Ig KCkKKyAgIkNoZWNrIHRoYXQgZGVidWdnZXIgcnVucyBvbiBgbWFrZS1wcm9jZXNzJyBmYWlsdXJl IChCdWcjMzMwMTYpLiIKKyAgKHNraXAtdW5sZXNzIChlcSBzeXN0ZW0tdHlwZSAnd2luZG93cy1u dCkpCisgIChsZXQqICgoZGVidWctb24tZXJyb3IgdCkKKyAgICAgICAgIChoYXZlLWNhbGxlZC1k ZWJ1Z2dlciBuaWwpCisgICAgICAgICAoZGVidWdnZXIgKGxhbWJkYSAoJnJlc3QgXykgKHNldHEg aGF2ZS1jYWxsZWQtZGVidWdnZXIgdCkpKSkKKyAgICAoc2hvdWxkIChlcSA6Z290LWVycm9yIDs7 IE5PVEU6IGBzaG91bGQtZXJyb3InIHdvdWxkIGluaGliaXQgZGVidWdnZXIuCisgICAgICAgICAg ICAgICAgKGNvbmRpdGlvbi1jYXNlLXVubGVzcy1kZWJ1ZyAoKQorICAgICAgICAgICAgICAgICAg ICA7OyBFbWFjcyBkb2Vzbid0IHNlYXJjaCBmb3IgYWJzb2x1dGUgZmlsZW5hbWVzLCBzbworICAg ICAgICAgICAgICAgICAgICA7OyB0aGUgZXJyb3Igd2lsbCBiZSBoaXQgaW4gdGhlIHczMiBwcm9j ZXNzIHNwYXduCisgICAgICAgICAgICAgICAgICAgIDs7IGNvZGUuCisgICAgICAgICAgICAgICAg ICAgIChtYWtlLXByb2Nlc3MgOm5hbWUgInRlc3QiIDpjb21tYW5kICcoImM6L05vLVN1Y2gtQ29t bWFuZCIpKQorICAgICAgICAgICAgICAgICAgKGVycm9yIDpnb3QtZXJyb3IpKSkpCisgICAgKHNo b3VsZCBoYXZlLWNhbGxlZC1kZWJ1Z2dlcikpKQorCiAoZXJ0LWRlZnRlc3QgbWFrZS1wcm9jZXNz L2ZpbGUtaGFuZGxlci9mb3VuZCAoKQogICAiQ2hlY2sgdGhhdCB0aGUg4oCYOmZpbGUtaGFuZGxl cuKAmSBhcmd1bWVudCBvZiDigJhtYWtlLXByb2Nlc3PigJkKIHdvcmtzIGFzIGV4cGVjdGVkIGlm IGEgZmlsZSBuYW1lIGhhbmRsZXIgaXMgZm91bmQuIgotLSAKMi42LjIud2luZG93cy4xCgo= --000000000000ecc7410586342caf-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 11 10:05:33 2019 Received: (at 33016) by debbugs.gnu.org; 11 Apr 2019 14:05:33 +0000 Received: from localhost ([127.0.0.1]:54987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEaKa-0003Sz-Or for submit@debbugs.gnu.org; Thu, 11 Apr 2019 10:05:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEaKW-0003Si-HY for 33016@debbugs.gnu.org; Thu, 11 Apr 2019 10:05:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEaKG-0001uu-CK; Thu, 11 Apr 2019 10:05:14 -0400 Received: from [176.228.60.248] (port=1762 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hEaK8-000533-BT; Thu, 11 Apr 2019 10:05:05 -0400 Date: Thu, 11 Apr 2019 17:04:46 +0300 Message-Id: <8336mo63k1.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Wed, 10 Apr 2019 17:58:43 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Date: Wed, 10 Apr 2019 17:58:43 -0400 > Cc: Klaus-Dieter Bauer , 33016@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. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 11 13:34:43 2019 Received: (at 33016) by debbugs.gnu.org; 11 Apr 2019 17:34:43 +0000 Received: from localhost ([127.0.0.1]:55130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEdb1-0004KY-74 for submit@debbugs.gnu.org; Thu, 11 Apr 2019 13:34:43 -0400 Received: from mail-oi1-f171.google.com ([209.85.167.171]:36954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEday-0004KL-GE for 33016@debbugs.gnu.org; Thu, 11 Apr 2019 13:34:41 -0400 Received: by mail-oi1-f171.google.com with SMTP id v84so5632754oif.4 for <33016@debbugs.gnu.org>; Thu, 11 Apr 2019 10:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Usd7xCP2GBKcaW4Qu5bHgekylGlwnPkcP58yUCoQq7E=; b=lbq6dv/8k2ypX6mfrhBqrlPfQMZtX5VQWY5pFZP+WOu60FOFYMioDdLDMzRyxfOJHN QxCwHzT2vL6dT8Wr3TDjmZXJqyer5K4BD4eeMwkypMvOPV/Cbiqt0Q3yFZJ+nl2tunA0 GGpnf+Ddv2U0vZcjArgLu17USCskib1G1iMc09Ry3LRMiax5M2UlXJ7Zmv7pNDFBCudE 9y0uizccSWo98YGDh3DIuNrhK5S06Z5me06Mh3fEgOWiU/6jLmkO4xjJhNhkNU4kZ6iv 3ARTLenOeD+lOeBAzZmHb6lp5DChWZiitnqLWKRlQXpjZhmkPCskbbH5ho+w5vaXykqX ebJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Usd7xCP2GBKcaW4Qu5bHgekylGlwnPkcP58yUCoQq7E=; b=eq5m7z/CX4jkDoGT7xORkc68AFvvQhA2SHdyDqlDFKUluyqECnQu4Ydzw0SSSVsfND OkQkxaJr2LteK1nkHp1ZWWE0Ojrt/O85XNL5dljZkRJhR2rezxfaPhVUlix6kf6f6nlJ +9hJLGC+MftwfM3V73hRvgcd8hsOuCd3poICFh5lv1c7I2VyUYAQbPavr2vShI4IcEKZ LEaK8EZXvqjssvGpYDIJ+aVr7DrojP0yXHTGzikhsIRFxj9Wbhc7crkr+vE9ADObGl1u dghCSQXy3lbxSIr5dSLKR3wKQR8M/ndVOL0S+YSk5O967DsMES5+Bok5k368UDfJAfSn u6og== X-Gm-Message-State: APjAAAUfx7q0vU0ECYE+TjtgWlzQo4vmK4lBO4St0Vw04XtTB3H+hzNW k6fcaBwBD0qbK1Tx1x+PVm9x484WueAfQipzPlQ= X-Google-Smtp-Source: APXvYqwY6Zma38McGvvkifUwjIZgIGadQI7sMU1zJOeP5F6MaFqfMAexqpEYvTZLsNsNTGY3ci4Lh4UNEg5zUADOUzQ= X-Received: by 2002:aca:32c2:: with SMTP id y185mr7602772oiy.177.1555004074663; Thu, 11 Apr 2019 10:34:34 -0700 (PDT) MIME-Version: 1.0 References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> In-Reply-To: <8336mo63k1.fsf@gnu.org> From: Noam Postavsky Date: Thu, 11 Apr 2019 13:34:25 -0400 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000007fd8c3058644993b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007fd8c3058644993b Content-Type: text/plain; charset="UTF-8" On Thu, 11 Apr 2019 at 10:05, Eli Zaretskii 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. --0000000000007fd8c3058644993b Content-Type: application/octet-stream; name="reset-when-entered.debugger.diff" Content-Disposition: attachment; filename="reset-when-entered.debugger.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juctl16w0 ZGlmZiAtLWdpdCBpL3NyYy8uZ2RiaW5pdCB3L3NyYy8uZ2RiaW5pdAppbmRleCBiOGIzMDMxLi4z MmIyNjgwIDEwMDY0NAotLS0gaS9zcmMvLmdkYmluaXQKKysrIHcvc3JjLy5nZGJpbml0CkBAIC0x MjI3LDYgKzEyMjcsNyBAQCBpZiBkZWZpbmVkX0hBVkVfWF9XSU5ET1dTCiAgIGJyZWFrIHhfZXJy b3JfcXVpdHRlcgogZW5kCiAKK2JyZWFrIEZyZWRyYXdfZGlzcGxheQogCiAjIFB1dCB0aGUgUHl0 aG9uIGNvZGUgYXQgdGhlIGVuZCBvZiAuZ2RiaW5pdCBzbyB0aGF0IGlmIEdEQiBkb2VzIG5vdAog IyBzdXBwb3J0IFB5dGhvbiwgR0RCIHdpbGwgZG8gYWxsIHRoZSBhYm92ZSBpbml0aWFsaXphdGlv bnMgYmVmb3JlCmRpZmYgLS1naXQgaS9zcmMvZXZhbC5jIHcvc3JjL2V2YWwuYwppbmRleCBlOWYx MThjLi42YzFhMmJiIDEwMDY0NAotLS0gaS9zcmMvZXZhbC5jCisrKyB3L3NyYy9ldmFsLmMKQEAg LTU5LDcgKzU5LDcgQEAgTGlzcF9PYmplY3QgVnJ1bl9ob29rczsKICAgIHNpZ25hbCB0aGUgZXJy b3IgaW5zdGVhZCBvZiBlbnRlcmluZyBhbiBpbmZpbml0ZSBsb29wIG9mIGRlYnVnZ2VyCiAgICBp bnZvY2F0aW9ucy4gICovCiAKLXN0YXRpYyBpbnRtYXhfdCB3aGVuX2VudGVyZWRfZGVidWdnZXI7 CisvL3N0YXRpYyBpbnRtYXhfdCB3aGVuX2VudGVyZWRfZGVidWdnZXI7CiAKIC8qIFRoZSBmdW5j dGlvbiBmcm9tIHdoaWNoIHRoZSBsYXN0IGBzaWduYWwnIHdhcyBjYWxsZWQuICBTZXQgaW4KICAg IEZzaWduYWwuICAqLwpAQCAtNDE3MCw2ICs0MTcwLDEyIEBAIE5vdGUgdGhhdCBgZGVidWctb24t ZXJyb3InLCBgZGVidWctb24tcXVpdCcgYW5kIGZyaWVuZHMKIHN0aWxsIGRldGVybWluZSB3aGV0 aGVyIHRvIGhhbmRsZSB0aGUgcGFydGljdWxhciBjb25kaXRpb24uICAqLyk7CiAgIFZkZWJ1Z19v bl9zaWduYWwgPSBRbmlsOwogCisgIERFRlNZTSAoUXdoZW5fZW50ZXJlZF9kZWJ1Z2dlciwgIndo ZW4tZW50ZXJlZC1kZWJ1Z2dlciIpOworICBERUZWQVJfSU5UICgid2hlbi1lbnRlcmVkLWRlYnVn Z2VyIiwgd2hlbl9lbnRlcmVkX2RlYnVnZ2VyLAorICAgICAgICAgICAgICBkb2M6IC8qIFRoZSBu dW1iZXIgb2Yga2V5Ym9hcmQgZXZlbnRzIGFzIG9mIGxhc3QgdGltZSBgZGVidWdnZXInIHdhcyBj YWxsZWQuCitVc2VkIHRvIGF2b2lkIGluZmluaXRlIGxvb3BzIGlmIHRoZSBkZWJ1Z2dlciBpdHNl bGYgaGFzIGFuIGVycm9yLgorRG9uJ3Qgc2V0IHRoaXMgdW5sZXNzIHlvdSdyZSBzdXJlIHRoYXQg Y2FuJ3QgaGFwcGVuLiAgKi8pOworCiAgIC8qIFdoZW4gbGV4aWNhbCBiaW5kaW5nIGlzIGJlaW5n IHVzZWQsCiAgICBWaW50ZXJuYWxfaW50ZXJwcmV0ZXJfZW52aXJvbm1lbnQgaXMgbm9uLW5pbCwg YW5kIGNvbnRhaW5zIGFuIGFsaXN0CiAgICBvZiBsZXhpY2FsbHktYm91bmQgdmFyaWFibGUsIG9y ICh0KSwgaW5kaWNhdGluZyBhbiBlbXB0eQpkaWZmIC0tZ2l0IGkvdGVzdC9zcmMvY2FsbHByb2Mt dGVzdHMuZWwgdy90ZXN0L3NyYy9jYWxscHJvYy10ZXN0cy5lbAppbmRleCBhMjcyOGEzLi4yOGY3 OTc1IDEwMDY0NAotLS0gaS90ZXN0L3NyYy9jYWxscHJvYy10ZXN0cy5lbAorKysgdy90ZXN0L3Ny Yy9jYWxscHJvYy10ZXN0cy5lbApAQCAtNDMsNyArNDMsMTIgQEAKICAgKHNraXAtdW5sZXNzIChl cSBzeXN0ZW0tdHlwZSAnd2luZG93cy1udCkpCiAgIChsZXQqICgoZGVidWctb24tZXJyb3IgdCkK ICAgICAgICAgIChoYXZlLWNhbGxlZC1kZWJ1Z2dlciBuaWwpCi0gICAgICAgICAoZGVidWdnZXIg KGxhbWJkYSAoJnJlc3QgXykgKHNldHEgaGF2ZS1jYWxsZWQtZGVidWdnZXIgdCkpKSkKKyAgICAg ICAgIChkZWJ1Z2dlciAobGFtYmRhICgmcmVzdCBfKQorICAgICAgICAgICAgICAgICAgICAgKHNl dHEgaGF2ZS1jYWxsZWQtZGVidWdnZXIgdCkKKyAgICAgICAgICAgICAgICAgICAgIDs7IEFsbG93 IGVudGVyaW5nIHRoZSBkZWJ1Z2dlciBsYXRlciBpbiB0aGUgc2FtZQorICAgICAgICAgICAgICAg ICAgICAgOzsgdGVzdCBydW4sIGJlZm9yZSBnb2luZyBiYWNrIHRvIHRoZSBjb21tYW5kCisgICAg ICAgICAgICAgICAgICAgICA7OyBsb29wLgorICAgICAgICAgICAgICAgICAgICAgKHNldHEgd2hl bi1lbnRlcmVkLWRlYnVnZ2VyIC0xKSkpKQogICAgIChzaG91bGQgKGVxIDpnb3QtZXJyb3IgOzsg Tk9URTogYHNob3VsZC1lcnJvcicgd291bGQgaW5oaWJpdCBkZWJ1Z2dlci4KICAgICAgICAgICAg ICAgICAoY29uZGl0aW9uLWNhc2UtdW5sZXNzLWRlYnVnICgpCiAgICAgICAgICAgICAgICAgICAg IDs7IE9uIFdpbmRvd3MsICJudWwuRk9PIiBpcyB0aGUgZW1wdHkgZmlsZSBmb3IgYW55CmRpZmYg LS1naXQgaS90ZXN0L3NyYy9wcm9jZXNzLXRlc3RzLmVsIHcvdGVzdC9zcmMvcHJvY2Vzcy10ZXN0 cy5lbAppbmRleCAyNWE1MmI3Li42NDBmMjkyIDEwMDY0NAotLS0gaS90ZXN0L3NyYy9wcm9jZXNz LXRlc3RzLmVsCisrKyB3L3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwKQEAgLTIyMCw3ICsyMjAs MTIgQEAgcHJvY2Vzcy10ZXN0cy0tbWl4YWJsZQogICAoc2tpcC11bmxlc3MgKGVxIHN5c3RlbS10 eXBlICd3aW5kb3dzLW50KSkKICAgKGxldCogKChkZWJ1Zy1vbi1lcnJvciB0KQogICAgICAgICAg KGhhdmUtY2FsbGVkLWRlYnVnZ2VyIG5pbCkKLSAgICAgICAgIChkZWJ1Z2dlciAobGFtYmRhICgm cmVzdCBfKSAoc2V0cSBoYXZlLWNhbGxlZC1kZWJ1Z2dlciB0KSkpKQorICAgICAgICAgKGRlYnVn Z2VyIChsYW1iZGEgKCZyZXN0IF8pCisgICAgICAgICAgICAgICAgICAgICAoc2V0cSBoYXZlLWNh bGxlZC1kZWJ1Z2dlciB0KQorICAgICAgICAgICAgICAgICAgICAgOzsgQWxsb3cgZW50ZXJpbmcg dGhlIGRlYnVnZ2VyIGxhdGVyIGluIHRoZSBzYW1lCisgICAgICAgICAgICAgICAgICAgICA7OyB0 ZXN0IHJ1biwgYmVmb3JlIGdvaW5nIGJhY2sgdG8gdGhlIGNvbW1hbmQKKyAgICAgICAgICAgICAg ICAgICAgIDs7IGxvb3AuCisgICAgICAgICAgICAgICAgICAgICAoc2V0cSB3aGVuLWVudGVyZWQt ZGVidWdnZXIgLTEpKSkpCiAgICAgKHNob3VsZCAoZXEgOmdvdC1lcnJvciA7OyBOT1RFOiBgc2hv dWxkLWVycm9yJyB3b3VsZCBpbmhpYml0IGRlYnVnZ2VyLgogICAgICAgICAgICAgICAgIChjb25k aXRpb24tY2FzZS11bmxlc3MtZGVidWcgKCkKICAgICAgICAgICAgICAgICAgICAgOzsgRW1hY3Mg ZG9lc24ndCBzZWFyY2ggZm9yIGFic29sdXRlIGZpbGVuYW1lcywgc28K --0000000000007fd8c3058644993b-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 11 13:56:14 2019 Received: (at 33016) by debbugs.gnu.org; 11 Apr 2019 17:56:14 +0000 Received: from localhost ([127.0.0.1]:55138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEdvq-0004ro-Dr for submit@debbugs.gnu.org; Thu, 11 Apr 2019 13:56:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEdvo-0004rb-Sg for 33016@debbugs.gnu.org; Thu, 11 Apr 2019 13:56:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEdvh-0000g4-B4; Thu, 11 Apr 2019 13:56:05 -0400 Received: from [176.228.60.248] (port=4166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hEdvV-0006jx-B6; Thu, 11 Apr 2019 13:55:57 -0400 Date: Thu, 11 Apr 2019 20:55:33 +0300 Message-Id: <83mukw4eay.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Thu, 11 Apr 2019 13:34:25 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Date: Thu, 11 Apr 2019 13:34:25 -0400 > Cc: Klaus-Dieter Bauer , 33016@debbugs.gnu.org > > > 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. OK. That diff includes some unrelated stuff, though -- you didn't mean to install it as is, right? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 11 20:44:26 2019 Received: (at 33016) by debbugs.gnu.org; 12 Apr 2019 00:44:26 +0000 Received: from localhost ([127.0.0.1]:55324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEkIr-0003zp-DW for submit@debbugs.gnu.org; Thu, 11 Apr 2019 20:44:26 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:42938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEkIp-0003zb-G1 for 33016@debbugs.gnu.org; Thu, 11 Apr 2019 20:44:24 -0400 Received: by mail-qt1-f169.google.com with SMTP id p20so9357770qtc.9 for <33016@debbugs.gnu.org>; Thu, 11 Apr 2019 17:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=M1xARmler6Lr4rI13cIFtOm7C2W/YPmX4MuqSSXMby8=; b=UVsDbvlKaKQX7j0MDB1k8a+w2npSb0bkpHzO1mU66Q+VTQtHv0HT/nFEoyVM3oayDz rgKDkOn2HPcqom8pN3ZINBVXivXiaUN/hqXcfO3RS/FpdqOwV0LQPgwvhWwi5E0hKtIR tPsZTHE2NmABkXUOpGMnXZJGQpx5ra4n83jF4pdstAvDGJpedeXRn7xSGxIsEXLY63P3 kVt3R7vIzIx1zu4wRBJQnvvFVx6kH+5O9sGqjlsMQFt71w0taXDGJ7o4qyikrcgxwfyJ Xzd8q3mLIZUb8nAQX8G0bjxZ1bIUzWQTwwLjMTSIHTy4d0CsDDeuz4N+H4K4HoeaR9hk 9eMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=M1xARmler6Lr4rI13cIFtOm7C2W/YPmX4MuqSSXMby8=; b=cK0Ids/EOz9o07OVgrDZgOUKBjkPQ+3D773GxFelO18lrSlkdo/yxYtEtUCCsrHsEX i6kH1eWDOF19r+YA9ClkfVdrW/3/+VaUtD6ah4WWdjYYrHsGzLE9qVU9k1rbHFeD3nKi l1I3uji8EoV7v8HnH0ce6TViu3mJby3K6DUfqc4eGXSleltOOA4GI6f6vV22prONsJLY bTcZpZ8Lul9dyC+yfpQ7DZNnG44/pLzF5ZnmBWQCwRySJqTa0MqnjN7wb7cLSvhGLSpm zEngbb4GpVj5ytqLl2K8QDasOq+iTih78cf/RJOvP8xp6UDRI4d/DD5K52K21wIvGPzw L6eQ== X-Gm-Message-State: APjAAAWSGY1hMjcRExDNyWqgTNy7aUi4pEuC3pvy0kPi1ehYAbZgbWVq KJ+wr7npmjAdV1H6w80qgYw= X-Google-Smtp-Source: APXvYqyfLKu+SWR9BiL7Ji9oQAaW+13NGU1xyZXI0aQ/3KZPHdQMibvFCkcSEvKYZG1B6Kz1/0H5dw== X-Received: by 2002:a0c:96fd:: with SMTP id b58mr43031628qvd.134.1555029857944; Thu, 11 Apr 2019 17:44:17 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id q23sm21652166qkc.16.2019.04.11.17.44.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Apr 2019 17:44:16 -0700 (PDT) From: Noam Postavsky To: Eli Zaretskii Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> <83mukw4eay.fsf@gnu.org> Date: Thu, 11 Apr 2019 20:44:15 -0400 In-Reply-To: <83mukw4eay.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 11 Apr 2019 20:55:33 +0300") Message-ID: <87ftqo9hnk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > OK. That diff includes some unrelated stuff, though -- you didn't > mean to install it as is, right? Ah, I left in the .gdbinit change completely by accident. The other stuff is related, but wasn't cleaned up properly yet. Here's a proper patch: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=v4-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch Content-Transfer-Encoding: quoted-printable Content-Description: patch >From a57d40ff5cab1bbd8f1a71bb9f062164a4f357d9 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Mon, 8 Apr 2019 17:57:22 -0400 Subject: [PATCH v4] Let debugger handle process spawn errors on w32 (Bug#33016) Since child_setup() is called between block_input()...unblock_input(), when an error is signaled the Lisp debugger is prevented from starting. Therefore, let the callers signal the error instead (which they already do for non-w32 platforms, just the error message needs an update). * src/callproc.c (child_setup) [WINDOWSNT]: Don't call report_file_error here. (call_process) [WINDOWNT]: * src/process.c (create_process) [WINDOWSNT]: Call report_file_errno here instead, after the unblock_input() call, same as for !WINDOWSNT. * src/lisp.h (CHILD_SETUP_ERROR_DESC): New preprocessor define. Flip the containing ifndef DOS_NT branches so that it's ifdef DOS_NT. * src/eval.c (when_entered_debugger): Remove. (syms_of_eval) : Define it as a Lisp integer variable instead. * test/src/process-tests.el (make-process-w32-debug-spawn-error): * test/src/callproc-tests.el (call-process-w32-debug-spawn-error): New tests. [2. text/x-diff; reset-when-entered.debugger.diff]... --- src/callproc.c | 7 ++----- src/eval.c | 21 ++++++++++++--------- src/lisp.h | 9 ++++++--- src/process.c | 2 +- test/src/callproc-tests.el | 21 +++++++++++++++++++++ test/src/process-tests.el | 20 ++++++++++++++++++++ 6 files changed, 62 insertions(+), 18 deletions(-) diff --git a/src/callproc.c b/src/callproc.c index a3d09609d7..2cdf84d9a8 100644 --- a/src/callproc.c +++ b/src/callproc.c @@ -681,7 +681,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int f= ilefd, unblock_input (); =20 if (pid < 0) - report_file_errno ("Doing vfork", Qnil, child_errno); + report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, child_errno); =20 /* Close our file descriptors, except for callproc_fd[CALLPROC_PIPEREAD] since we will use that to read input from. */ @@ -1174,7 +1174,7 @@ exec_failed (char const *name, int err) executable directory by the parent. =20 On GNUish hosts, either exec or return an error number. - On MS-Windows, either return a pid or signal an error. + On MS-Windows, either return a pid or return -1 and set errno. On MS-DOS, either return an exit status or signal an error. */ =20 CHILD_SETUP_TYPE @@ -1319,9 +1319,6 @@ child_setup (int in, int out, int err, char **new_arg= v, bool set_pgrp, /* Spawn the child. (See w32proc.c:sys_spawnve). */ cpid =3D spawnve (_P_NOWAIT, new_argv[0], new_argv, env); reset_standard_handles (in, out, err, handles); - if (cpid =3D=3D -1) - /* An error occurred while trying to spawn the process. */ - report_file_error ("Spawning child process", Qnil); return cpid; =20 #else /* not WINDOWSNT */ diff --git a/src/eval.c b/src/eval.c index e9f118c5cb..adc94724f3 100644 --- a/src/eval.c +++ b/src/eval.c @@ -52,15 +52,6 @@ Lisp_Object Vautoload_queue; is shutting down. */ Lisp_Object Vrun_hooks; =20 -/* 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; - /* The function from which the last `signal' was called. Set in Fsignal. */ /* FIXME: We should probably get rid of this! */ @@ -4170,6 +4161,18 @@ Note that `debug-on-error', `debug-on-quit' and frie= nds still determine whether to handle the particular condition. */); Vdebug_on_signal =3D Qnil; =20 + DEFSYM (Qinternal_when_entered_debugger, "internal-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. */ + DEFVAR_INT ("internal-when-entered-debugger", when_entered_debugger, + doc: /* The number of keyboard events as of last time `debug= ger' 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 a/src/lisp.h b/src/lisp.h index 681efc3b52..2915944ffe 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4480,11 +4480,14 @@ extern void syms_of_process (void); extern void setup_process_coding_systems (Lisp_Object); =20 /* Defined in callproc.c. */ -#ifndef DOS_NT -# define CHILD_SETUP_TYPE _Noreturn void -#else +#ifdef DOS_NT # define CHILD_SETUP_TYPE int +# define CHILD_SETUP_ERROR_DESC "Spawning child process" +#else +# define CHILD_SETUP_TYPE _Noreturn void +# define CHILD_SETUP_ERROR_DESC "Doing vfork" #endif + extern CHILD_SETUP_TYPE child_setup (int, int, int, char **, bool, Lisp_Ob= ject); extern void init_callproc_1 (void); extern void init_callproc (void); diff --git a/src/process.c b/src/process.c index 6770a5ed88..0c44037162 100644 --- a/src/process.c +++ b/src/process.c @@ -2233,7 +2233,7 @@ create_process (Lisp_Object process, char **new_argv,= Lisp_Object current_dir) unblock_input (); =20 if (pid < 0) - report_file_errno ("Doing vfork", Qnil, vfork_errno); + report_file_errno (CHILD_SETUP_ERROR_DESC, Qnil, vfork_errno); else { /* vfork succeeded. */ diff --git a/test/src/callproc-tests.el b/test/src/callproc-tests.el index 7b30a251cc..28f7975fcc 100644 --- a/test/src/callproc-tests.el +++ b/test/src/callproc-tests.el @@ -37,3 +37,24 @@ (ert-deftest initial-environment-preserved () (split-string-and-unquote (buffer-string))) (should (equal initial-shell "nil")) (should-not (equal initial-shell shell)))) + +(ert-deftest call-process-w32-debug-spawn-error () + "Check that debugger runs on `call-process' failure (Bug#33016)." + (skip-unless (eq system-type 'windows-nt)) + (let* ((debug-on-error t) + (have-called-debugger nil) + (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 + ;; FOO, in any directory. So this passes Emacs' + ;; test for the file's existence, and ensures we + ;; hit an error in the w32 process spawn code. + (call-process "c:/nul.exe") + (error :got-error)))) + (should have-called-debugger))) diff --git a/test/src/process-tests.el b/test/src/process-tests.el index 5dbf441e8c..640f292df5 100644 --- a/test/src/process-tests.el +++ b/test/src/process-tests.el @@ -215,6 +215,26 @@ (ert-deftest make-process/mix-stderr () (string-to-list "stdout\n") (string-to-list "stderr\n")))))) =20 +(ert-deftest make-process-w32-debug-spawn-error () + "Check that debugger runs on `make-process' failure (Bug#33016)." + (skip-unless (eq system-type 'windows-nt)) + (let* ((debug-on-error t) + (have-called-debugger nil) + (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 + ;; the error will be hit in the w32 process spawn + ;; code. + (make-process :name "test" :command '("c:/No-Such-Comm= and")) + (error :got-error)))) + (should have-called-debugger))) + (ert-deftest make-process/file-handler/found () "Check that the =E2=80=98:file-handler=E2=80=99 argument of =E2=80=98mak= e-process=E2=80=99 works as expected if a file name handler is found." --=20 2.11.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 12 04:45:14 2019 Received: (at 33016) by debbugs.gnu.org; 12 Apr 2019 08:45:14 +0000 Received: from localhost ([127.0.0.1]:55429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEroA-0000x1-8l for submit@debbugs.gnu.org; Fri, 12 Apr 2019 04:45:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hEro9-0000wn-6N for 33016@debbugs.gnu.org; Fri, 12 Apr 2019 04:45:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEro3-0001e8-Rm; Fri, 12 Apr 2019 04:45:07 -0400 Received: from [176.228.60.248] (port=3982 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hEro2-0001JH-Sy; Fri, 12 Apr 2019 04:45:07 -0400 Date: Fri, 12 Apr 2019 11:44:49 +0300 Message-Id: <83imvjmx32.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: <87ftqo9hnk.fsf@gmail.com> (message from Noam Postavsky on Thu, 11 Apr 2019 20:44:15 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> <83mukw4eay.fsf@gnu.org> <87ftqo9hnk.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com > Date: Thu, 11 Apr 2019 20:44:15 -0400 > > > OK. That diff includes some unrelated stuff, though -- you didn't > > mean to install it as is, right? > > Ah, I left in the .gdbinit change completely by accident. The other > stuff is related, but wasn't cleaned up properly yet. Here's a proper patch: Thanks. > + ;; On Windows, "nul.FOO" is the empty file for any > + ;; FOO, in any directory. So this passes Emacs' > + ;; test for the file's existence, and ensures we > + ;; hit an error in the w32 process spawn code. > + (call-process "c:/nul.exe") What happened to mentioning the null device in this comment? > + (setq when-entered-debugger -1)))) This should be internal-when-entered-debugger, right? And the same in the other test. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 12 14:21:06 2019 Received: (at 33016) by debbugs.gnu.org; 12 Apr 2019 18:21:06 +0000 Received: from localhost ([127.0.0.1]:56687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hF0nR-0002YB-Uw for submit@debbugs.gnu.org; Fri, 12 Apr 2019 14:21:06 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:45351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hF0nO-0002XG-Ch for 33016@debbugs.gnu.org; Fri, 12 Apr 2019 14:21:04 -0400 Received: by mail-oi1-f194.google.com with SMTP id y84so8730114oia.12 for <33016@debbugs.gnu.org>; Fri, 12 Apr 2019 11:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CN3HwSwyXsoabLoiuwuEYmCczcD4bRHPBeUdoYGxgP0=; b=plSShEcosSo1wY6z+1jHAK72ZzKwy2t14ai9KYsRqVRiFiOtemgWNlvHADcB9oWy1O RJcBfUph9bK4j/9ZFMFvyAHn26DPdVfYaDKmcxbHi2zHUeqHBugoCHu8I8oCeGFdsh68 Jx8MP+KRLZ/V8/PKRZykBSQsvc/6XGZ7AnnB1o7icAnC89K+rRqSshIcjt4oBhKmtgLC 0jvQysTkv9oqdq3sphKrmN05a5KmZKDt5+3HJJ+L8zrtU6CfNXTk5+LJA3McPzizJTsO F6kgpcolu6sSNKylAlnHK10dN/7svD9Ulu7gzXXkWBoUPDhlgwmFybKx8BXx02lLdrgW RFmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CN3HwSwyXsoabLoiuwuEYmCczcD4bRHPBeUdoYGxgP0=; b=N4KUnc+7VrskAMzYcBDpbQDt4N8ENWuyvpexHlXZNGKuXgzpjwh/SOiGMYb+S4Rq7M kl++LIodP8MdY7jFX9Ee9wR0SAEctjoHUFrYbe3ThpYr5dPpP/5SobCVnUd+oW6jwahB CJ0LOw0nEBGSKmt1IniN4QptwtqOsEtq/YI4oxrTlAm+oChJI0TPw5KAYbubeWnXAnxI PapmyzS2FKaf9hBRVtYRByv63ZK5eQ1gXcthJ1f9ddG/9FnQP5eA3Ew9lnlUWXaV710a P+iBQP3vZ9zFR4yc+e5OBWMuL6gZDgV5wnMYTBqD5+csYYvf8fJlD9yExYso9MDVQcMc 5u8g== X-Gm-Message-State: APjAAAUolT6eDG/ddK7YCn3scMCoUxg+7aL/Oh/kI5eOYMoY7FCf0m0l AXMLo72OJ91/FN196oeLov60Ktl1InXYHbP4eoM= X-Google-Smtp-Source: APXvYqzQKlaOd72o58f6K+QGDCbZbVd1rliM9V/dosS2jtrGHKkBlOquPFnrR310ki7fJcpYYp/UZkG5shbnidfl8BY= X-Received: by 2002:aca:bf08:: with SMTP id p8mr10447181oif.173.1555093256521; Fri, 12 Apr 2019 11:20:56 -0700 (PDT) MIME-Version: 1.0 References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> <83mukw4eay.fsf@gnu.org> <87ftqo9hnk.fsf@gmail.com> <83imvjmx32.fsf@gnu.org> In-Reply-To: <83imvjmx32.fsf@gnu.org> From: Noam Postavsky Date: Fri, 12 Apr 2019 14:20:46 -0400 Message-ID: Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000002653d20586595db1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000002653d20586595db1 Content-Type: text/plain; charset="UTF-8" On Fri, 12 Apr 2019 at 04:45, Eli Zaretskii wrote: > > + ;; On Windows, "nul.FOO" is the empty file for any > > + ;; FOO, in any directory. So this passes Emacs' > > + ;; test for the file's existence, and ensures we > > + ;; hit an error in the w32 process spawn code. > > + (call-process "c:/nul.exe") > > What happened to mentioning the null device in this comment? Yeah, I forgot to change this comment (though I don't think specifically naming the null device is needed). > > + (setq when-entered-debugger -1)))) > > This should be internal-when-entered-debugger, right? And the same in > the other test. Oops, right, that's what I get for rushing things. I think got everything this time (include replacing RMS' question in eval.c). --0000000000002653d20586595db1 Content-Type: application/octet-stream; name="v5-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Disposition: attachment; filename="v5-0001-Let-debugger-handle-process-spawn-errors-on-w32-B.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juee9hnw0 RnJvbSBiODVkNTdlN2Q1ZTAyMDE1MDJkOWZhNGY5MzMzMzRkYTc1ZWYyYTYxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBNb24sIDggQXByIDIwMTkgMTc6NTc6MjIgLTA0MDAKU3ViamVjdDogW1BBVENIIHY1XSBM ZXQgZGVidWdnZXIgaGFuZGxlIHByb2Nlc3Mgc3Bhd24gZXJyb3JzIG9uIHczMgogKEJ1ZyMzMzAx NikKClNpbmNlIGNoaWxkX3NldHVwKCkgaXMgY2FsbGVkIGJldHdlZW4gYmxvY2tfaW5wdXQoKS4u LnVuYmxvY2tfaW5wdXQoKSwKd2hlbiBhbiBlcnJvciBpcyBzaWduYWxlZCB0aGUgTGlzcCBkZWJ1 Z2dlciBpcyBwcmV2ZW50ZWQgZnJvbQpzdGFydGluZy4gIFRoZXJlZm9yZSwgbGV0IHRoZSBjYWxs ZXJzIHNpZ25hbCB0aGUgZXJyb3IgaW5zdGVhZCAod2hpY2gKdGhleSBhbHJlYWR5IGRvIGZvciBu b24tdzMyIHBsYXRmb3JtcywganVzdCB0aGUgZXJyb3IgbWVzc2FnZSBuZWVkcyBhbgp1cGRhdGUp LgoqIHNyYy9jYWxscHJvYy5jIChjaGlsZF9zZXR1cCkgW1dJTkRPV1NOVF06IERvbid0IGNhbGwK cmVwb3J0X2ZpbGVfZXJyb3IgaGVyZS4KKGNhbGxfcHJvY2VzcykgW1dJTkRPV05UXToKKiBzcmMv cHJvY2Vzcy5jIChjcmVhdGVfcHJvY2VzcykgW1dJTkRPV1NOVF06IENhbGwgcmVwb3J0X2ZpbGVf ZXJybm8KaGVyZSBpbnN0ZWFkLCBhZnRlciB0aGUgdW5ibG9ja19pbnB1dCgpIGNhbGwsIHNhbWUg YXMgZm9yICFXSU5ET1dTTlQuCiogc3JjL2xpc3AuaCAoQ0hJTERfU0VUVVBfRVJST1JfREVTQyk6 IE5ldyBwcmVwcm9jZXNzb3IgZGVmaW5lLiAgRmxpcAp0aGUgY29udGFpbmluZyBpZm5kZWYgRE9T X05UIGJyYW5jaGVzIHNvIHRoYXQgaXQncyBpZmRlZiBET1NfTlQuCiogc3JjL2V2YWwuYyAod2hl bl9lbnRlcmVkX2RlYnVnZ2VyKTogUmVtb3ZlLgooc3ltc19vZl9ldmFsKSA8aW50ZXJuYWwtd2hl bi1lbnRlcmVkLWRlYnVnZ2VyPjogRGVmaW5lIGl0IGFzIGEgTGlzcAppbnRlZ2VyIHZhcmlhYmxl IGluc3RlYWQuCihtYXliZV9jYWxsX2RlYnVnZ2VyKTogVXBkYXRlIGNvbW1lbnQuCiogdGVzdC9z cmMvcHJvY2Vzcy10ZXN0cy5lbCAobWFrZS1wcm9jZXNzLXczMi1kZWJ1Zy1zcGF3bi1lcnJvcik6 CiogdGVzdC9zcmMvY2FsbHByb2MtdGVzdHMuZWwgKGNhbGwtcHJvY2Vzcy13MzItZGVidWctc3Bh d24tZXJyb3IpOiBOZXcKdGVzdHMuCi0tLQogc3JjL2NhbGxwcm9jLmMgICAgICAgICAgICAgfCAg NyArKy0tLS0tCiBzcmMvZXZhbC5jICAgICAgICAgICAgICAgICB8IDI0ICsrKysrKysrKysrKysr LS0tLS0tLS0tLQogc3JjL2xpc3AuaCAgICAgICAgICAgICAgICAgfCAgOSArKysrKystLS0KIHNy Yy9wcm9jZXNzLmMgICAgICAgICAgICAgIHwgIDIgKy0KIHRlc3Qvc3JjL2NhbGxwcm9jLXRlc3Rz LmVsIHwgMjIgKysrKysrKysrKysrKysrKysrKysrKwogdGVzdC9zcmMvcHJvY2Vzcy10ZXN0cy5l bCAgfCAyMCArKysrKysrKysrKysrKysrKysrKwogNiBmaWxlcyBjaGFuZ2VkLCA2NSBpbnNlcnRp b25zKCspLCAxOSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvY2FsbHByb2MuYyBiL3Ny Yy9jYWxscHJvYy5jCmluZGV4IGEzZDA5NjAuLjJjZGY4NGQgMTAwNjQ0Ci0tLSBhL3NyYy9jYWxs cHJvYy5jCisrKyBiL3NyYy9jYWxscHJvYy5jCkBAIC02ODEsNyArNjgxLDcgQEAgY2FsbF9wcm9j ZXNzIChwdHJkaWZmX3QgbmFyZ3MsIExpc3BfT2JqZWN0ICphcmdzLCBpbnQgZmlsZWZkLAogICB1 bmJsb2NrX2lucHV0ICgpOwogCiAgIGlmIChwaWQgPCAwKQotICAgIHJlcG9ydF9maWxlX2Vycm5v ICgiRG9pbmcgdmZvcmsiLCBRbmlsLCBjaGlsZF9lcnJubyk7CisgICAgcmVwb3J0X2ZpbGVfZXJy bm8gKENISUxEX1NFVFVQX0VSUk9SX0RFU0MsIFFuaWwsIGNoaWxkX2Vycm5vKTsKIAogICAvKiBD bG9zZSBvdXIgZmlsZSBkZXNjcmlwdG9ycywgZXhjZXB0IGZvciBjYWxscHJvY19mZFtDQUxMUFJP Q19QSVBFUkVBRF0KICAgICAgc2luY2Ugd2Ugd2lsbCB1c2UgdGhhdCB0byByZWFkIGlucHV0IGZy b20uICAqLwpAQCAtMTE3NCw3ICsxMTc0LDcgQEAgZXhlY19mYWlsZWQgKGNoYXIgY29uc3QgKm5h bWUsIGludCBlcnIpCiAgICBleGVjdXRhYmxlIGRpcmVjdG9yeSBieSB0aGUgcGFyZW50LgogCiAg ICBPbiBHTlVpc2ggaG9zdHMsIGVpdGhlciBleGVjIG9yIHJldHVybiBhbiBlcnJvciBudW1iZXIu Ci0gICBPbiBNUy1XaW5kb3dzLCBlaXRoZXIgcmV0dXJuIGEgcGlkIG9yIHNpZ25hbCBhbiBlcnJv ci4KKyAgIE9uIE1TLVdpbmRvd3MsIGVpdGhlciByZXR1cm4gYSBwaWQgb3IgcmV0dXJuIC0xIGFu ZCBzZXQgZXJybm8uCiAgICBPbiBNUy1ET1MsIGVpdGhlciByZXR1cm4gYW4gZXhpdCBzdGF0dXMg b3Igc2lnbmFsIGFuIGVycm9yLiAgKi8KIAogQ0hJTERfU0VUVVBfVFlQRQpAQCAtMTMxOSw5ICsx MzE5LDYgQEAgY2hpbGRfc2V0dXAgKGludCBpbiwgaW50IG91dCwgaW50IGVyciwgY2hhciAqKm5l d19hcmd2LCBib29sIHNldF9wZ3JwLAogICAvKiBTcGF3biB0aGUgY2hpbGQuICAoU2VlIHczMnBy b2MuYzpzeXNfc3Bhd252ZSkuICAqLwogICBjcGlkID0gc3Bhd252ZSAoX1BfTk9XQUlULCBuZXdf YXJndlswXSwgbmV3X2FyZ3YsIGVudik7CiAgIHJlc2V0X3N0YW5kYXJkX2hhbmRsZXMgKGluLCBv dXQsIGVyciwgaGFuZGxlcyk7Ci0gIGlmIChjcGlkID09IC0xKQotICAgIC8qIEFuIGVycm9yIG9j Y3VycmVkIHdoaWxlIHRyeWluZyB0byBzcGF3biB0aGUgcHJvY2Vzcy4gICovCi0gICAgcmVwb3J0 X2ZpbGVfZXJyb3IgKCJTcGF3bmluZyBjaGlsZCBwcm9jZXNzIiwgUW5pbCk7CiAgIHJldHVybiBj cGlkOwogCiAjZWxzZSAgLyogbm90IFdJTkRPV1NOVCAqLwpkaWZmIC0tZ2l0IGEvc3JjL2V2YWwu YyBiL3NyYy9ldmFsLmMKaW5kZXggZTlmMTE4Yy4uZmE3YjJkMCAxMDA2NDQKLS0tIGEvc3JjL2V2 YWwuYworKysgYi9zcmMvZXZhbC5jCkBAIC01MiwxNSArNTIsNiBAQCBMaXNwX09iamVjdCBWYXV0 b2xvYWRfcXVldWU7CiAgICBpcyBzaHV0dGluZyBkb3duLiAgKi8KIExpc3BfT2JqZWN0IFZydW5f aG9va3M7CiAKLS8qIFRoZSB2YWx1ZSBvZiBudW1fbm9ubWFjcm9faW5wdXRfZXZlbnRzIGFzIG9m IHRoZSBsYXN0IHRpbWUgd2UKLSAgIHN0YXJ0ZWQgdG8gZW50ZXIgdGhlIGRlYnVnZ2VyLiAgSWYg d2UgZGVjaWRlIHRvIGVudGVyIHRoZSBkZWJ1Z2dlcgotICAgYWdhaW4gd2hlbiB0aGlzIGlzIHN0 aWxsIGVxdWFsIHRvIG51bV9ub25tYWNyb19pbnB1dF9ldmVudHMsIHRoZW4gd2UKLSAgIGtub3cg dGhhdCB0aGUgZGVidWdnZXIgaXRzZWxmIGhhcyBhbiBlcnJvciwgYW5kIHdlIHNob3VsZCBqdXN0 Ci0gICBzaWduYWwgdGhlIGVycm9yIGluc3RlYWQgb2YgZW50ZXJpbmcgYW4gaW5maW5pdGUgbG9v cCBvZiBkZWJ1Z2dlcgotICAgaW52b2NhdGlvbnMuICAqLwotCi1zdGF0aWMgaW50bWF4X3Qgd2hl bl9lbnRlcmVkX2RlYnVnZ2VyOwotCiAvKiBUaGUgZnVuY3Rpb24gZnJvbSB3aGljaCB0aGUgbGFz dCBgc2lnbmFsJyB3YXMgY2FsbGVkLiAgU2V0IGluCiAgICBGc2lnbmFsLiAgKi8KIC8qIEZJWE1F OiBXZSBzaG91bGQgcHJvYmFibHkgZ2V0IHJpZCBvZiB0aGlzISAgKi8KQEAgLTE4MzUsNyArMTgy Niw4IEBAIG1heWJlX2NhbGxfZGVidWdnZXIgKExpc3BfT2JqZWN0IGNvbmRpdGlvbnMsIExpc3Bf T2JqZWN0IHNpZywgTGlzcF9PYmplY3QgZGF0YSkKIAkgID8gZGVidWdfb25fcXVpdAogCSAgOiB3 YW50c19kZWJ1Z2dlciAoVmRlYnVnX29uX2Vycm9yLCBjb25kaXRpb25zKSkKICAgICAgICYmICEg c2tpcF9kZWJ1Z2dlciAoY29uZGl0aW9ucywgY29tYmluZWRfZGF0YSkKLSAgICAgIC8qIFJNUzog V2hhdCdzIHRoaXMgZm9yPyAgKi8KKyAgICAgIC8qIFNlZSBjb21tZW50YXJ5IG9uIGRlZmluaXRp b24gb2YKKyAgICAgICAgIGBpbnRlcm5hbC13aGVuLWVudGVyZWQtZGVidWdnZXInLiAgKi8KICAg ICAgICYmIHdoZW5fZW50ZXJlZF9kZWJ1Z2dlciA8IG51bV9ub25tYWNyb19pbnB1dF9ldmVudHMp CiAgICAgewogICAgICAgY2FsbF9kZWJ1Z2dlciAobGlzdDIgKFFlcnJvciwgY29tYmluZWRfZGF0 YSkpOwpAQCAtNDE3MCw2ICs0MTYyLDE4IEBAIE5vdGUgdGhhdCBgZGVidWctb24tZXJyb3InLCBg ZGVidWctb24tcXVpdCcgYW5kIGZyaWVuZHMKIHN0aWxsIGRldGVybWluZSB3aGV0aGVyIHRvIGhh bmRsZSB0aGUgcGFydGljdWxhciBjb25kaXRpb24uICAqLyk7CiAgIFZkZWJ1Z19vbl9zaWduYWwg PSBRbmlsOwogCisgIC8qIFRoZSB2YWx1ZSBvZiBudW1fbm9ubWFjcm9faW5wdXRfZXZlbnRzIGFz IG9mIHRoZSBsYXN0IHRpbWUgd2UKKyAgIHN0YXJ0ZWQgdG8gZW50ZXIgdGhlIGRlYnVnZ2VyLiAg SWYgd2UgZGVjaWRlIHRvIGVudGVyIHRoZSBkZWJ1Z2dlcgorICAgYWdhaW4gd2hlbiB0aGlzIGlz IHN0aWxsIGVxdWFsIHRvIG51bV9ub25tYWNyb19pbnB1dF9ldmVudHMsIHRoZW4gd2UKKyAgIGtu b3cgdGhhdCB0aGUgZGVidWdnZXIgaXRzZWxmIGhhcyBhbiBlcnJvciwgYW5kIHdlIHNob3VsZCBq dXN0CisgICBzaWduYWwgdGhlIGVycm9yIGluc3RlYWQgb2YgZW50ZXJpbmcgYW4gaW5maW5pdGUg bG9vcCBvZiBkZWJ1Z2dlcgorICAgaW52b2NhdGlvbnMuICAqLworICBERUZTWU0gKFFpbnRlcm5h bF93aGVuX2VudGVyZWRfZGVidWdnZXIsICJpbnRlcm5hbC13aGVuLWVudGVyZWQtZGVidWdnZXIi KTsKKyAgREVGVkFSX0lOVCAoImludGVybmFsLXdoZW4tZW50ZXJlZC1kZWJ1Z2dlciIsIHdoZW5f ZW50ZXJlZF9kZWJ1Z2dlciwKKyAgICAgICAgICAgICAgZG9jOiAvKiBUaGUgbnVtYmVyIG9mIGtl eWJvYXJkIGV2ZW50cyBhcyBvZiBsYXN0IHRpbWUgYGRlYnVnZ2VyJyB3YXMgY2FsbGVkLgorVXNl ZCB0byBhdm9pZCBpbmZpbml0ZSBsb29wcyBpZiB0aGUgZGVidWdnZXIgaXRzZWxmIGhhcyBhbiBl cnJvci4KK0Rvbid0IHNldCB0aGlzIHVubGVzcyB5b3UncmUgc3VyZSB0aGF0IGNhbid0IGhhcHBl bi4gICovKTsKKwogICAvKiBXaGVuIGxleGljYWwgYmluZGluZyBpcyBiZWluZyB1c2VkLAogICAg VmludGVybmFsX2ludGVycHJldGVyX2Vudmlyb25tZW50IGlzIG5vbi1uaWwsIGFuZCBjb250YWlu cyBhbiBhbGlzdAogICAgb2YgbGV4aWNhbGx5LWJvdW5kIHZhcmlhYmxlLCBvciAodCksIGluZGlj YXRpbmcgYW4gZW1wdHkKZGlmZiAtLWdpdCBhL3NyYy9saXNwLmggYi9zcmMvbGlzcC5oCmluZGV4 IDY4MWVmYzMuLjI5MTU5NDQgMTAwNjQ0Ci0tLSBhL3NyYy9saXNwLmgKKysrIGIvc3JjL2xpc3Au aApAQCAtNDQ4MCwxMSArNDQ4MCwxNCBAQCBleHRlcm4gdm9pZCBzeW1zX29mX3Byb2Nlc3MgKHZv aWQpOwogZXh0ZXJuIHZvaWQgc2V0dXBfcHJvY2Vzc19jb2Rpbmdfc3lzdGVtcyAoTGlzcF9PYmpl Y3QpOwogCiAvKiBEZWZpbmVkIGluIGNhbGxwcm9jLmMuICAqLwotI2lmbmRlZiBET1NfTlQKLSMg ZGVmaW5lIENISUxEX1NFVFVQX1RZUEUgX05vcmV0dXJuIHZvaWQKLSNlbHNlCisjaWZkZWYgRE9T X05UCiAjIGRlZmluZSBDSElMRF9TRVRVUF9UWVBFIGludAorIyBkZWZpbmUgQ0hJTERfU0VUVVBf RVJST1JfREVTQyAiU3Bhd25pbmcgY2hpbGQgcHJvY2VzcyIKKyNlbHNlCisjIGRlZmluZSBDSElM RF9TRVRVUF9UWVBFIF9Ob3JldHVybiB2b2lkCisjIGRlZmluZSBDSElMRF9TRVRVUF9FUlJPUl9E RVNDICJEb2luZyB2Zm9yayIKICNlbmRpZgorCiBleHRlcm4gQ0hJTERfU0VUVVBfVFlQRSBjaGls ZF9zZXR1cCAoaW50LCBpbnQsIGludCwgY2hhciAqKiwgYm9vbCwgTGlzcF9PYmplY3QpOwogZXh0 ZXJuIHZvaWQgaW5pdF9jYWxscHJvY18xICh2b2lkKTsKIGV4dGVybiB2b2lkIGluaXRfY2FsbHBy b2MgKHZvaWQpOwpkaWZmIC0tZ2l0IGEvc3JjL3Byb2Nlc3MuYyBiL3NyYy9wcm9jZXNzLmMKaW5k ZXggNjc3MGE1ZS4uMGM0NDAzNyAxMDA2NDQKLS0tIGEvc3JjL3Byb2Nlc3MuYworKysgYi9zcmMv cHJvY2Vzcy5jCkBAIC0yMjMzLDcgKzIyMzMsNyBAQCBjcmVhdGVfcHJvY2VzcyAoTGlzcF9PYmpl Y3QgcHJvY2VzcywgY2hhciAqKm5ld19hcmd2LCBMaXNwX09iamVjdCBjdXJyZW50X2RpcikKICAg dW5ibG9ja19pbnB1dCAoKTsKIAogICBpZiAocGlkIDwgMCkKLSAgICByZXBvcnRfZmlsZV9lcnJu byAoIkRvaW5nIHZmb3JrIiwgUW5pbCwgdmZvcmtfZXJybm8pOworICAgIHJlcG9ydF9maWxlX2Vy cm5vIChDSElMRF9TRVRVUF9FUlJPUl9ERVNDLCBRbmlsLCB2Zm9ya19lcnJubyk7CiAgIGVsc2UK ICAgICB7CiAgICAgICAvKiB2Zm9yayBzdWNjZWVkZWQuICAqLwpkaWZmIC0tZ2l0IGEvdGVzdC9z cmMvY2FsbHByb2MtdGVzdHMuZWwgYi90ZXN0L3NyYy9jYWxscHJvYy10ZXN0cy5lbAppbmRleCA3 YjMwYTI1Li5mMzUxYjZlIDEwMDY0NAotLS0gYS90ZXN0L3NyYy9jYWxscHJvYy10ZXN0cy5lbAor KysgYi90ZXN0L3NyYy9jYWxscHJvYy10ZXN0cy5lbApAQCAtMzcsMyArMzcsMjUgQEAKICAgICAg ICAgKHNwbGl0LXN0cmluZy1hbmQtdW5xdW90ZSAoYnVmZmVyLXN0cmluZykpKQogICAgIChzaG91 bGQgKGVxdWFsIGluaXRpYWwtc2hlbGwgIm5pbCIpKQogICAgIChzaG91bGQtbm90IChlcXVhbCBp bml0aWFsLXNoZWxsIHNoZWxsKSkpKQorCisoZXJ0LWRlZnRlc3QgY2FsbC1wcm9jZXNzLXczMi1k ZWJ1Zy1zcGF3bi1lcnJvciAoKQorICAiQ2hlY2sgdGhhdCBkZWJ1Z2dlciBydW5zIG9uIGBjYWxs LXByb2Nlc3MnIGZhaWx1cmUgKEJ1ZyMzMzAxNikuIgorICAoc2tpcC11bmxlc3MgKGVxIHN5c3Rl bS10eXBlICd3aW5kb3dzLW50KSkKKyAgKGxldCogKChkZWJ1Zy1vbi1lcnJvciB0KQorICAgICAg ICAgKGhhdmUtY2FsbGVkLWRlYnVnZ2VyIG5pbCkKKyAgICAgICAgIChkZWJ1Z2dlciAobGFtYmRh ICgmcmVzdCBfKQorICAgICAgICAgICAgICAgICAgICAgKHNldHEgaGF2ZS1jYWxsZWQtZGVidWdn ZXIgdCkKKyAgICAgICAgICAgICAgICAgICAgIDs7IEFsbG93IGVudGVyaW5nIHRoZSBkZWJ1Z2dl ciBsYXRlciBpbiB0aGUgc2FtZQorICAgICAgICAgICAgICAgICAgICAgOzsgdGVzdCBydW4sIGJl Zm9yZSBnb2luZyBiYWNrIHRvIHRoZSBjb21tYW5kCisgICAgICAgICAgICAgICAgICAgICA7OyBs b29wLgorICAgICAgICAgICAgICAgICAgICAgKHNldHEgaW50ZXJuYWwtd2hlbi1lbnRlcmVkLWRl YnVnZ2VyIC0xKSkpKQorICAgIChzaG91bGQgKGVxIDpnb3QtZXJyb3IgOzsgTk9URTogYHNob3Vs ZC1lcnJvcicgd291bGQgaW5oaWJpdCBkZWJ1Z2dlci4KKyAgICAgICAgICAgICAgICAoY29uZGl0 aW9uLWNhc2UtdW5sZXNzLWRlYnVnICgpCisgICAgICAgICAgICAgICAgICAgIDs7IE9uIFdpbmRv d3MsICJudWwuRk9PIiBhY3QgbGlrZSBhbiBhbHdheXMtZW1wdHkKKyAgICAgICAgICAgICAgICAg ICAgOzsgZmlsZSBmb3IgYW55IEZPTywgaW4gYW55IGRpcmVjdG9yeS4gIFNvIHRoaXMKKyAgICAg ICAgICAgICAgICAgICAgOzsgcGFzc2VzIEVtYWNzJyB0ZXN0IGZvciB0aGUgZmlsZSdzIGV4aXN0 ZW5jZSwKKyAgICAgICAgICAgICAgICAgICAgOzsgYW5kIGVuc3VyZXMgd2UgaGl0IGFuIGVycm9y IGluIHRoZSB3MzIgcHJvY2VzcworICAgICAgICAgICAgICAgICAgICA7OyBzcGF3biBjb2RlLgor ICAgICAgICAgICAgICAgICAgICAoY2FsbC1wcm9jZXNzICJjOi9udWwuZXhlIikKKyAgICAgICAg ICAgICAgICAgIChlcnJvciA6Z290LWVycm9yKSkpKQorICAgIChzaG91bGQgaGF2ZS1jYWxsZWQt ZGVidWdnZXIpKSkKZGlmZiAtLWdpdCBhL3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwgYi90ZXN0 L3NyYy9wcm9jZXNzLXRlc3RzLmVsCmluZGV4IDVkYmY0NDEuLjBiYjdlYmUgMTAwNjQ0Ci0tLSBh L3Rlc3Qvc3JjL3Byb2Nlc3MtdGVzdHMuZWwKKysrIGIvdGVzdC9zcmMvcHJvY2Vzcy10ZXN0cy5l bApAQCAtMjE1LDYgKzIxNSwyNiBAQCBwcm9jZXNzLXRlc3RzLS1taXhhYmxlCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmctdG8tbGlzdCAic3Rkb3V0XG4iKQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoc3RyaW5nLXRvLWxpc3QgInN0 ZGVyclxuIikpKSkpKQogCisoZXJ0LWRlZnRlc3QgbWFrZS1wcm9jZXNzLXczMi1kZWJ1Zy1zcGF3 bi1lcnJvciAoKQorICAiQ2hlY2sgdGhhdCBkZWJ1Z2dlciBydW5zIG9uIGBtYWtlLXByb2Nlc3Mn IGZhaWx1cmUgKEJ1ZyMzMzAxNikuIgorICAoc2tpcC11bmxlc3MgKGVxIHN5c3RlbS10eXBlICd3 aW5kb3dzLW50KSkKKyAgKGxldCogKChkZWJ1Zy1vbi1lcnJvciB0KQorICAgICAgICAgKGhhdmUt Y2FsbGVkLWRlYnVnZ2VyIG5pbCkKKyAgICAgICAgIChkZWJ1Z2dlciAobGFtYmRhICgmcmVzdCBf KQorICAgICAgICAgICAgICAgICAgICAgKHNldHEgaGF2ZS1jYWxsZWQtZGVidWdnZXIgdCkKKyAg ICAgICAgICAgICAgICAgICAgIDs7IEFsbG93IGVudGVyaW5nIHRoZSBkZWJ1Z2dlciBsYXRlciBp biB0aGUgc2FtZQorICAgICAgICAgICAgICAgICAgICAgOzsgdGVzdCBydW4sIGJlZm9yZSBnb2lu ZyBiYWNrIHRvIHRoZSBjb21tYW5kCisgICAgICAgICAgICAgICAgICAgICA7OyBsb29wLgorICAg ICAgICAgICAgICAgICAgICAgKHNldHEgaW50ZXJuYWwtd2hlbi1lbnRlcmVkLWRlYnVnZ2VyIC0x KSkpKQorICAgIChzaG91bGQgKGVxIDpnb3QtZXJyb3IgOzsgTk9URTogYHNob3VsZC1lcnJvcicg d291bGQgaW5oaWJpdCBkZWJ1Z2dlci4KKyAgICAgICAgICAgICAgICAoY29uZGl0aW9uLWNhc2Ut dW5sZXNzLWRlYnVnICgpCisgICAgICAgICAgICAgICAgICAgIDs7IEVtYWNzIGRvZXNuJ3Qgc2Vh cmNoIGZvciBhYnNvbHV0ZSBmaWxlbmFtZXMsIHNvCisgICAgICAgICAgICAgICAgICAgIDs7IHRo ZSBlcnJvciB3aWxsIGJlIGhpdCBpbiB0aGUgdzMyIHByb2Nlc3Mgc3Bhd24KKyAgICAgICAgICAg ICAgICAgICAgOzsgY29kZS4KKyAgICAgICAgICAgICAgICAgICAgKG1ha2UtcHJvY2VzcyA6bmFt ZSAidGVzdCIgOmNvbW1hbmQgJygiYzovTm8tU3VjaC1Db21tYW5kIikpCisgICAgICAgICAgICAg ICAgICAoZXJyb3IgOmdvdC1lcnJvcikpKSkKKyAgICAoc2hvdWxkIGhhdmUtY2FsbGVkLWRlYnVn Z2VyKSkpCisKIChlcnQtZGVmdGVzdCBtYWtlLXByb2Nlc3MvZmlsZS1oYW5kbGVyL2ZvdW5kICgp CiAgICJDaGVjayB0aGF0IHRoZSDigJg6ZmlsZS1oYW5kbGVy4oCZIGFyZ3VtZW50IG9mIOKAmG1h a2UtcHJvY2Vzc+KAmQogd29ya3MgYXMgZXhwZWN0ZWQgaWYgYSBmaWxlIG5hbWUgaGFuZGxlciBp cyBmb3VuZC4iCi0tIAoyLjYuMi53aW5kb3dzLjEKCg== --0000000000002653d20586595db1-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 12 14:44:32 2019 Received: (at 33016) by debbugs.gnu.org; 12 Apr 2019 18:44:32 +0000 Received: from localhost ([127.0.0.1]:56693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hF1A8-00036u-0T for submit@debbugs.gnu.org; Fri, 12 Apr 2019 14:44:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hF1A6-00036i-0I for 33016@debbugs.gnu.org; Fri, 12 Apr 2019 14:44:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hF1A0-0001YF-J8; Fri, 12 Apr 2019 14:44:24 -0400 Received: from [176.228.60.248] (port=1313 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hF19z-0007bP-Og; Fri, 12 Apr 2019 14:44:24 -0400 Date: Fri, 12 Apr 2019 21:44:08 +0300 Message-Id: <83tvf3kqrr.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Fri, 12 Apr 2019 14:20:46 -0400) Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> <83mukw4eay.fsf@gnu.org> <87ftqo9hnk.fsf@gmail.com> <83imvjmx32.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Date: Fri, 12 Apr 2019 14:20:46 -0400 > Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer > > Oops, right, that's what I get for rushing things. I think got > everything this time (include replacing RMS' question in eval.c). OK, thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 15 08:21:57 2019 Received: (at 33016) by debbugs.gnu.org; 15 Apr 2019 12:21:57 +0000 Received: from localhost ([127.0.0.1]:34214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hG0cX-0002hP-B3 for submit@debbugs.gnu.org; Mon, 15 Apr 2019 08:21:57 -0400 Received: from mail-qt1-f173.google.com ([209.85.160.173]:36159) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hG0cU-0002h4-ID; Mon, 15 Apr 2019 08:21:55 -0400 Received: by mail-qt1-f173.google.com with SMTP id s15so18787793qtn.3; Mon, 15 Apr 2019 05:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=U1PsxSJpbuM9tA4//K0JA+mgHMCspa7Kf8drEzrQnuw=; b=vReeY0JspQ3TlIkbNN0OjKO6Ta7eP0zqhJbajoFDMpP2m00MFLSxX0ptMvWAwPh7ps nLh6zY/yVAYZCAQHEmnn7wtDQXVzlIsyLqZi8RuX44TMSmf09WVSy7ObbSiSxi2Wd/gm YfJw1zwkAlgXgIAGMCNWjdjpn2JQU22hJ0+n/SnVdWTThYY8sifH9jFzd+qgNVM1HiIh mrxbBbgqSOuuV01v9iU+gRy/O+sMFk1a5W2O0WTU70+SeFOPZp1/gNe1oQ1Dw32VgWam pj1E07gjKnbW59LC4N3NrNA5a9BeqrqMFrbzPyNT2wB26gOgF5M3Jui4+7Lw+5xD+rfq k7tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=U1PsxSJpbuM9tA4//K0JA+mgHMCspa7Kf8drEzrQnuw=; b=EEF2R2YIhTmJWgTNYLB3Mn8AKVTTkSYTON5SO5tpzlY/0maLfQPPvdQFHEt9250FxG MGsoxOeNApMxA+sUxVT27C7kEfcnSO3Wb1rh5fw1zoNhdRNwnyO7BZ6SWgm6rVZJ6/hW Ul2hfTFswY3m4HeRCxYSt9M2tadKzbSb48CUdsApXbVk2r7P5sAqEv6i9TYLD6k+KewG uaCL2K2kI4Y2UB9MkGk9U4F79Daq3yOzknBQF6APNshdsRrBkaD9c/Pw4iedsdn541bf N+/ECJTmrFzsdoRDUFer5KIduTxaJGchXKk8iNcKDpVaRoLQ39PNLkLYRRkQaG3H3GYR NB8Q== X-Gm-Message-State: APjAAAWugpkJ8fVTOH9nw0poZHajGDmFjy97SpVYtYmC5sO8MU2Ym6gf xPN/9NvAdKgk2qTt89RLPU6RzcSY X-Google-Smtp-Source: APXvYqwS9kMvW+QDtWOveKsvLyVM92StlxWOOpmJgvOYxGJY3oTlwRJc5vV8cvoAvm5iJjvTY0Z6tw== X-Received: by 2002:aed:3aaa:: with SMTP id o39mr60815217qte.100.1555330907937; Mon, 15 Apr 2019 05:21:47 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id l59sm29662782qte.6.2019.04.15.05.21.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Apr 2019 05:21:46 -0700 (PDT) From: Noam Postavsky To: Eli Zaretskii Subject: Re: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist References: <83y34k728d.fsf@gnu.org> <83bm1f6yfl.fsf@gnu.org> <8336mo63k1.fsf@gnu.org> <83mukw4eay.fsf@gnu.org> <87ftqo9hnk.fsf@gmail.com> <83imvjmx32.fsf@gnu.org> <83tvf3kqrr.fsf@gnu.org> Date: Mon, 15 Apr 2019 08:21:45 -0400 In-Reply-To: <83tvf3kqrr.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Apr 2019 21:44:08 +0300") Message-ID: <87v9zfzcfa.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33016 Cc: 33016@debbugs.gnu.org, bauer.klaus.dieter@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 33016 fixed close 33016 27.1 quit Eli Zaretskii writes: >> From: Noam Postavsky >> Date: Fri, 12 Apr 2019 14:20:46 -0400 >> Cc: 33016@debbugs.gnu.org, Klaus-Dieter Bauer >> >> Oops, right, that's what I get for rushing things. I think got >> everything this time (include replacing RMS' question in eval.c). > > OK, thanks. Pushed to master. 9800df69cb 2019-04-14T22:43:38-04:00 "Let debugger handle process spawn errors on w32 (Bug#33016)" From unknown Fri Jun 13 16:53:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 14 May 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator