GNU bug report logs -
#71655
Eshell external commands do not work under GNU Emacs for Windows
Previous Next
Full log
View this message in rfc822 format
On 6/19/2024 9:53 PM, Eli Zaretskii wrote:
>> Date: Wed, 19 Jun 2024 12:40:12 -0700
>> Cc: 71655 <at> debbugs.gnu.org, james <at> literate-devops.io
>> From: Jim Porter <jporterbugs <at> 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.
This bug report was last modified 203 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.