GNU bug report logs -
#37576
27.0.50; [Windows] "Permission denied" error from call-process if executable not found
Previous Next
Reported by: Richard Copley <rcopley <at> gmail.com>
Date: Tue, 1 Oct 2019 19:45:02 UTC
Severity: normal
Found in version 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37576 in the body.
You can then email your comments to 37576 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 19:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Richard Copley <rcopley <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 01 Oct 2019 19:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In "emacs -Q", if the file "xyzzy" does not exist on the path,
(call-process "xyzzy") now leaves this in the *Messages* buffer:
forward-sexp: Searching for program: Permission denied, xyzzy
In older versions the entry in the message buffer is a true statement:
eval: Searching for program: No such file or directory, xyzzy
(I also noticed debug-on-error is now 't' in "emacs -Q". This isn't in the
NEWS, unless I missed it?)
In GNU Emacs 27.0.50 (build 13, x86_64-w64-mingw32)
of 2019-10-01 built on MACHINE
Repository revision: cbc507779b8f56ce0abf596416e8e3847de88e10
Repository branch: buster
Windowing system distributor 'Microsoft Corp.', version 10.0.18890
System Description: Microsoft Windows 10 Pro (v10.0.1903.18890.1000)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Entering debugger...
Continuing.
forward-sexp: Searching for program: Permission denied, xyzzy
Configured using:
'configure --config-cache --with-modules --without-pop --without-dbus
--without-gconf --without-gsettings 'CFLAGS=-O0 -ggdb3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: ENG
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 dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile compile comint ansi-color ring cconv
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils help-fns radix-tree cl-print debug backtrace help-mode
easymenu find-func cl-loaddefs cl-lib 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 threads w32notify w32 lcms2 multi-tty make-network-process
emacs)
Memory information:
((conses 16 56362 12184)
(symbols 48 6971 1)
(strings 32 19777 2016)
(string-bytes 1 617340)
(vectors 16 11386)
(vector-slots 8 141766 11600)
(floats 8 25 161)
(intervals 56 229 7)
(buffers 992 12))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 20:44:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Oct 1, 2019 at 9:56 PM Richard Copley <rcopley <at> gmail.com> wrote:
> In "emacs -Q", if the file "xyzzy" does not exist on the path,
(call-process "xyzzy") now leaves this in the *Messages* buffer:
>
> forward-sexp: Searching for program: Permission denied, xyzzy
>
> In older versions the entry in the message buffer is a true statement:
>
> eval: Searching for program: No such file or directory, xyzzy
In the current trunk, I get "No such file on directory".
ELISP> (call-process "xyzzy")
*** Eval error *** Searching for program: No such file or directory, xyzzy
> Repository revision: cbc507779b8f56ce0abf596416e8e3847de88e10
> Repository branch: buster
After Paul changes adding more strict file checking, there were some fixes
to ease up. Perhaps you got a revision in between. I cannot say, because
the repository revision of your report is likely some local change by you
(it's not in the public repository).
> (I also noticed debug-on-error is now 't' in "emacs -Q".
C:> emacs.exe -Q --batch --eval "(princ debug-on-error)"
nil
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 22:07:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 1 Oct 2019 at 21:43, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Tue, Oct 1, 2019 at 9:56 PM Richard Copley <rcopley <at> gmail.com> wrote:
>
> > In "emacs -Q", if the file "xyzzy" does not exist on the path,
> (call-process "xyzzy") now leaves this in the *Messages* buffer:
> >
> > forward-sexp: Searching for program: Permission denied, xyzzy
> >
> > In older versions the entry in the message buffer is a true statement:
> >
> > eval: Searching for program: No such file or directory, xyzzy
>
> In the current trunk, I get "No such file on directory".
>
> ELISP> (call-process "xyzzy")
> *** Eval error *** Searching for program: No such file or directory, xyzzy
>
> > Repository revision: cbc507779b8f56ce0abf596416e8e3847de88e10
> > Repository branch: buster
>
> After Paul changes adding more strict file checking, there were some fixes
> to ease up. Perhaps you got a revision in between. I cannot say, because
> the repository revision of your report is likely some local change by you
> (it's not in the public repository).
>
I get the same results in "emacs -Q" rebuilt from scratch from current
pristine master, 2698d3dba2 (2019-10-01 23:15:03 2019 +0300). After
building and running using this command...:
git reset --hard 2698d3db && git clean -xfd && ./autogen.sh &&
./configure && make && src/emacs.exe -Q
...the recipe below pops up the Lisp debugger.
M-: (call-process SPC "xyzzy") RET
c ;; debugger-continue
On continuing in the debugger, it prints "forward-sexp: Searching for
program: Permission denied, xyzzy" in the *Messages* buffer.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 22:18:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 2, 2019 at 12:06 AM Richard Copley <rcopley <at> gmail.com> wrote:
> On continuing in the debugger, it prints "forward-sexp: Searching for
program: Permission denied, xyzzy" in the *Messages* buffer.
With that very same revision, just bootstrapped a few minutes ago, and with
your recipe, I get
forward-sexp: Searching for program: No such file or directory, xyzzy
This is on Windows 10, with a MSYS2 64-bit build.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 22:30:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 1 Oct 2019 at 23:17, Juanma Barranquero <lekktu <at> gmail.com> wrote:
>
>
> On Wed, Oct 2, 2019 at 12:06 AM Richard Copley <rcopley <at> gmail.com> wrote:
>
> > On continuing in the debugger, it prints "forward-sexp: Searching for
> program: Permission denied, xyzzy" in the *Messages* buffer.
>
> With that very same revision, just bootstrapped a few minutes ago, and
> with your recipe, I get
>
> forward-sexp: Searching for program: No such file or directory, xyzzy
>
> This is on Windows 10, with a MSYS2 64-bit build.
>
Same here. No big deal, I guess I'll get used to it.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 22:34:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Assuming that with "Same here" you're talking about the building
environment and operating system (because obviously the messages are
dissimilar)... That's puzzling.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 22:41:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 1 Oct 2019 at 23:33, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> Assuming that with "Same here" you're talking about the building
> environment and operating system (because obviously the messages are
> dissimilar)... That's puzzling.
>
Yes.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Tue, 01 Oct 2019 23:57:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 2, 2019 at 12:40 AM Richard Copley <rcopley <at> gmail.com> wrote:
>That's puzzling.
Ok.
I get your message if I add to PATH a non-existent (or, I suppose,
non-accesible) directory.
So, if you have such a directory in your PATH, the message you get is
correct, because it happens before call-process can totally determine that
it can not find "xyzzy".
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 09:22:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 37576 <at> debbugs.gnu.org (full text, mbox):
Richard Copley <rcopley <at> gmail.com> writes:
> (I also noticed debug-on-error is now 't' in "emacs -Q". This isn't in
> the NEWS, unless I missed it?)
That variable it not `t', but there's a new variable called
`eval-expression-debug-on-error' that's in effect when you `M-:', and
`debug-on-error' is bound to whatever that variable is in that command.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 10:09:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 37576 <at> debbugs.gnu.org (full text, mbox):
On Okt 02 2019, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> So, if you have such a directory in your PATH, the message you get is
> correct, because it happens before call-process can totally determine that
> it can not find "xyzzy".
No, non-existing PATH elements are supposed to be ignored.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 10:20:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 2, 2019 at 12:07 PM Andreas Schwab <schwab <at> linux-m68k.org>
wrote:
> No, non-existing PATH elements are supposed to be ignored.
Ok, let me rephrase this.
Non-existent PATH element are ignored when searching, if the program is
found.
When the search fails, Emacs is now reporting "permission denied" if some
PATH element was non-existent, or "no such file or directory" otherwise. At
least on Windows.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 11:03:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 37576 <at> debbugs.gnu.org (full text, mbox):
On Okt 02 2019, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> When the search fails, Emacs is now reporting "permission denied" if some
> PATH element was non-existent, or "no such file or directory" otherwise. At
> least on Windows.
And that is a bug. A PATH element pointing to a non-existing directory
should be ignored.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 11:49:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 2, 2019 at 1:02 PM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> And that is a bug. A PATH element pointing to a non-existing directory
> should be ignored.
Just out of curiosity... Says who? I mean, there's a standard (POSIX or
whatever) that says what kind of error message you should give when
searching the PATH and not finding what you were looking for? Or it just
states that non-existing elements should be ignored, in the sense of not
stopping the search?
Not arguing, genuinely curious.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 12:59:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 37576 <at> debbugs.gnu.org (full text, mbox):
On Okt 02 2019, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Wed, Oct 2, 2019 at 1:02 PM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>
>> And that is a bug. A PATH element pointing to a non-existing directory
>> should be ignored.
>
> Just out of curiosity... Says who?
That's how the shell behaves.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 13:19:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> That's how the shell behaves.
Ok.
In this specific case, which is trying to run a program and failing from
inside Emacs, I think it could be argued both ways: that it is more
informative to know there's something a bit off in your PATH, or that it is
irrelevant, because the relevant info is that the program couldn't be run.
I suppose the answer to "one way or the other" is "Yes, as long as it is
consistently done in all platforms."
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 16:49:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 37576 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Date: Wed, 02 Oct 2019 13:02:43 +0200
> Cc: Richard Copley <rcopley <at> gmail.com>, 37576 <at> debbugs.gnu.org
>
> On Okt 02 2019, Juanma Barranquero <lekktu <at> gmail.com> wrote:
>
> > When the search fails, Emacs is now reporting "permission denied" if some
> > PATH element was non-existent, or "no such file or directory" otherwise. At
> > least on Windows.
>
> And that is a bug. A PATH element pointing to a non-existing directory
> should be ignored.
I don't know what "ignore" means in this case, since call-process
should signal an error if it's unable to find the program. If you
mean that nonexistent directories should be treated as if they
existed, but didn't have the program in them, then I agree, and I've
now fixed the Windows build's behavior to match that of the Posix
builds in this case.
I still didn't hear from Richard confirming that his case is indeed
caused by a non-existent directory on PATH. Maybe there are other
factors at work here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37576
; Package
emacs
.
(Wed, 02 Oct 2019 17:10:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 37576 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 2 Oct 2019 at 17:48, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Andreas Schwab <schwab <at> linux-m68k.org>
> > Date: Wed, 02 Oct 2019 13:02:43 +0200
> > Cc: Richard Copley <rcopley <at> gmail.com>, 37576 <at> debbugs.gnu.org
> >
> > On Okt 02 2019, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> >
> > > When the search fails, Emacs is now reporting "permission denied" if
> some
> > > PATH element was non-existent, or "no such file or directory"
> otherwise. At
> > > least on Windows.
> >
> > And that is a bug. A PATH element pointing to a non-existing directory
> > should be ignored.
>
> I don't know what "ignore" means in this case, since call-process
> should signal an error if it's unable to find the program. If you
> mean that nonexistent directories should be treated as if they
> existed, but didn't have the program in them, then I agree, and I've
> now fixed the Windows build's behavior to match that of the Posix
> builds in this case.
>
I agree with that too, FWIW. Thanks.
> I still didn't hear from Richard confirming that his case is indeed
> caused by a non-existent directory on PATH.
Yes it is. (At least, there *are* non-existent directories in PATH, and I
get the correct message now.)
Maybe there are other
> factors at work here.
>
[Message part 2 (text/html, inline)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 02 Oct 2019 17:20:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Richard Copley <rcopley <at> gmail.com>
:
bug acknowledged by developer.
(Wed, 02 Oct 2019 17:20:03 GMT)
Full text and
rfc822 format available.
Message #58 received at 37576-done <at> debbugs.gnu.org (full text, mbox):
> From: Richard Copley <rcopley <at> gmail.com>
> Date: Wed, 2 Oct 2019 18:09:14 +0100
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>, Juanma Barranquero <lekktu <at> gmail.com>, 37576 <at> debbugs.gnu.org
>
> I don't know what "ignore" means in this case, since call-process
> should signal an error if it's unable to find the program. If you
> mean that nonexistent directories should be treated as if they
> existed, but didn't have the program in them, then I agree, and I've
> now fixed the Windows build's behavior to match that of the Posix
> builds in this case.
>
> I agree with that too, FWIW. Thanks.
>
> I still didn't hear from Richard confirming that his case is indeed
> caused by a non-existent directory on PATH.
>
> Yes it is. (At least, there are non-existent directories in PATH, and I get the correct message now.)
Thanks, then it's time to close this bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 31 Oct 2019 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 291 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.