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

[Jim Porter <jporterbugs@gmail.com>]

On 6/19/2024 9:53 PM, Eli Zaretskii wrote:
>> Date: Wed, 19 Jun 2024 12:40:12 -0700
>> Cc: 71655@debbugs.gnu.org, james@literate-devops.io
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> 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).

'file-regular-p' for that file is also non-nil. Should we change that?

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

My version of ls reports it as a symlink, interestingly enough. I'm 
using the MSYS2 binaries that come with Git for Windows to test this. I 
think they apply some additional patches on top so maybe the versions I 
have include some special support for reparse points like this?

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

Well, I don't think size=0 is the only way that we could skip over files 
like this. If 'file-regular-p' or 'file-readable-p' returned nil, we 
could use that to skip it. We could also skip files ending in ".exe". We 
could skip files that signal from 'insert-file-contents-literally'.

I don't mind checking for size=0 if that's what we decide, but my 
reading of the existing 'eshell-script-interpreter' suggests that it 
should have already worked. If there's a bug in 'file-regular-p' (or 
some other function Eshell uses here), I think it's work fixing it at 
the source so that we squash the bug once and for all. Otherwise, some 
other Lisp code might try to do something similar one day (maybe a Lisp 
version of file(1)?) and get bitten by this bug.

If that's not convincing, then I'll just add the size=0 check.