GNU bug report logs - #30564
call-process always fails for empty exec-path

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30564 in the body.
You can then email your comments to 30564 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Christopher Wellons <wellons <at> nullprogram.com>
To: bug-gnu-emacs <at> gnu.org
Subject: call-process always fails for empty exec-path
Date: Tue, 20 Feb 2018 21:07:36 -0500

The call-process function incorrectly fails for valid absolute paths 
when exec-path is nil:

   (let ((exec-path ()))
     (call-process "/bin/ls"))
   ;; error: (file-error "Searching for program"
   ;;                    "No such file or directory" "/bin/ls")

Adding a single element to exec-path fixes the problem, even if that 
element is nonsense:

   (let ((exec-path '(t)))
     (call-process "/bin/ls"))
   ;; => 0

The bug is in the for loop in openp() (lread.c). The only successful 
returns are found inside the loop. An empty list results in no loop 
iterations, which means an absolute path has no chance to return 
successfully.

This bug dates back at least as far as Emacs 24.3.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Christopher Wellons <wellons <at> nullprogram.com>
Cc: 30564 <at> debbugs.gnu.org
Subject: Re: bug#30564: call-process always fails for empty exec-path
Date: Sat, 14 Apr 2018 21:56:38 +0200

Christopher Wellons <wellons <at> nullprogram.com> writes:

> The call-process function incorrectly fails for valid absolute paths
> when exec-path is nil:
>
>    (let ((exec-path ()))
>      (call-process "/bin/ls"))
>    ;; error: (file-error "Searching for program"
>    ;;                    "No such file or directory" "/bin/ls")
>
> Adding a single element to exec-path fixes the problem, even if that
> element is nonsense:
>
>    (let ((exec-path '(t)))
>      (call-process "/bin/ls"))
>    ;; => 0
>
> The bug is in the for loop in openp() (lread.c). The only successful
> returns are found inside the loop. An empty list results in no loop
> iterations, which means an absolute path has no chance to return
> successfully.

I've now fixed this by transforming the for loop into a do/while loop.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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