bug#71655: Eshell external commands do not work under GNU Emacs for Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 19 Jun 2024 12:40:12 -0700
> Cc: 71655@debbugs.gnu.org, james@literate-devops.io
> From: Jim Porter <jporterbugs@gmail.com>
> 
> 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.

It fails because winget.exe is not a regular file, and
insert-file-contents barely supports non-regular files (and even that
almost exclusively on Posix systems).

> 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's a reparse point, but not a symlink.  Symlinks are also
implemented on Windows as reparse points, but this one is a reparse
point of a different kind, because Emacs does support symlinks on
MS-Windows, and yet doesn't recognize this file as a symlink.

> 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).

Not here.  The native cat.exe says "Invalid argument", just like
Emacs, and the one from MSYS says "Permission denied".  I get similar
errors from other utilities, for example wc.  And MSYS ls shows it as
a regular file of size zero.

So I think what we see in Emacs is the same issue with these special
"executables" they cannot be easily treated as regular files or links
to regular files.

> 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.

See above: I hope I explained that now.

> 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).

I'm asking why it even makes sense to try to read these files?  If a
file is not a symlink and its size is zero, what useful things could
possibly happen by trying to read it?  Suppose we add to Emacs support
for these special reparse points -- what do you expect the target to
be if the name ends with .exe? what kind of "interpreter" will we
glean from that?

So my opinion on this is that Eshell should really skip reading files
whose size is zero when it looks for an interpreter, since we will
never find anything useful that way.