GNU bug report logs - #71655
Eshell external commands do not work under GNU Emacs for Windows

Previous Next

Full log

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71655 <at> debbugs.gnu.org, james <at> literate-devops.io
Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs
 for Windows
Date: Wed, 19 Jun 2024 12:40:12 -0700

On 6/19/2024 12:22 PM, Eli Zaretskii wrote:
> Jim, why does Eshell want to read the executable file winget.exe?  If
> that's because it wants to find the signature by which it will deduce
> the interpreter, then doing that for zero-size files is not useful,
> and should probably be skipped?

It's trying to find a shebang, which I guess(?) is so that Eshell can 
support shebangs on MS-Windows. What's strange is that 'file-readable-p' 
is non-nil, but 'insert-file-contents-literally' fails.

As far as I understand things, winget.exe isn't exactly a zero-byte 
file. They're reparse points that point to a real executable living in 
some locked-down folder, so they're like something symlinks I think?

It seems like there's a small bug somewhere in 
'insert-file-contents-literally'. On MS-Windows, "cat 
C:\Users\...\winget.exe" outputs the (binary) contents of winget.exe 
just fine (this is using the MSYS2 build of cat). So I think the real 
winget.exe file truly is readable. I don't know why 
'insert-file-contents-literally' has a problem with it though.

It'd be nice to figure out why that fails and fix it at the source, but 
on the other hand, maybe this only comes up when trying to read these 
.exe files? A more-targeted fix could be to just ignore errors in 
'eshell-script-interpreter': if we can't insert the file, assume it 
doesn't have a shebang and try to run it like a normal program (which 
works fine in Emacs).

Previous Next

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