GNU bug report logs -
#71655
Eshell external commands do not work under GNU Emacs for Windows
Previous Next
Full log
Message #26 received at 71655 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 Jun 2024 22:34:02 -0700
> Cc: 71655 <at> debbugs.gnu.org, james <at> literate-devops.io
> From: Jim Porter <jporterbugs <at> gmail.com>
>
> 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?
Only if that is useful. For now, I'm not sure I see a reason to do
that, since the code to support that will not be trivial, and will
have to include full support for these files in file-attributes and
similar APIs as well.
> > 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.
It isn't a symlink. It is a reparse point of type APPEXECLINK, which
has different attributes and different data structure describing the
target. We could represent it as a symlink (since Posix has no direct
equivalent), but the implementation under the hood will need to be
different.
> > 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 agree that all those other conditions (including the .exe test) seem
to be reasonable, in addition to zero-size.
> 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.
Fixing file-regular-p (and all the related APIs) for this purpose
sounds like a lot of work for little or no gain. But if someone wants
to work on that and provide a clean patch, I don't mind.
> 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.
When they do, we'll have another situation to consider.
In general, you must understand that the depth and breadth of
emulating Posix assumptions and concepts on MS-Windows are driven by
practical needs, not by theoretical possibilities and potential
breakage that _might_ happen in some hypothetical Lisp. Especially as
I don't quite see people with such patches lining up...
So if a simpler change in the (so far) single application which bumped
into this could fix the problem, I'm all for it.
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.