From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Klaus-Dieter Bauer Newsgroups: gmane.emacs.bugs Subject: bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist Date: Fri, 19 Oct 2018 10:03:00 +0200 Message-ID: References: <835zy8y34x.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009dcace057890569b" X-Trace: blaine.gmane.org 1539936139 16025 195.159.176.226 (19 Oct 2018 08:02:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 08:02:19 +0000 (UTC) Cc: 33016@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 19 10:02:14 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDPjV-0003ye-Op for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2018 10:02:09 +0200 Original-Received: from localhost ([::1]:47652 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDPlc-0004HH-2y for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2018 04:04:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDPlP-0004GO-Du for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 04:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDPlL-00024G-Pc for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 04:04:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53837) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDPlL-00022f-HQ for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 04:04:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gDPlK-00085R-K6 for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 04:04:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Klaus-Dieter Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Oct 2018 08:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33016 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33016-submit@debbugs.gnu.org id=B33016.153993621731054 (code B ref 33016); Fri, 19 Oct 2018 08:04:02 +0000 Original-Received: (at 33016) by debbugs.gnu.org; 19 Oct 2018 08:03:37 +0000 Original-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 Original-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 Original-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) In-Reply-To: <835zy8y34x.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151426 Archived-At: --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--