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

Previous Next

Package: emacs;

Reported by: James Hilling <james <at> literate-devops.io>

Date: Wed, 19 Jun 2024 18:50:02 UTC

Severity: normal

Merged with 74150

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 71655-done <at> debbugs.gnu.org, james <at> literate-devops.io
Subject: bug#71655: Eshell external commands do not work under GNU Emacs for Windows
Date: Mon, 08 Jul 2024 14:09:39 +0300
> Date: Sun, 7 Jul 2024 20:26:17 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 71655-done <at> debbugs.gnu.org,
>  james <at> literate-devops.io
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 6/23/2024 10:56 PM, Michael Albinus via Bug reports for GNU Emacs, 
> the Swiss army knife of text editors wrote:
> > Jim Porter <jporterbugs <at> gmail.com> writes:
> > 
> >> I'll think about this some more and see if we can get all the checks
> >> we want without making the code slower over Tramp. (Maybe Tramp caches
> >> enough that this isn't a problem, but I'm not certain yet.)
> > 
> > If Eshell calls `process-file', it shall bind `process-file-side-effects'
> > to nil if appropriate for the given command.
> > 
> > Furthermore, Eshell might bind `remote-file-name-inhibit-cache' to
> > something which helps. The default value (10) seems to be very conservative.
> After looking into this, it turns out Eshell doesn't look for a shebang 
> on remote files (a comment in 'eshell-connection-local-command' claims 
> that it doesn't work with Tramp syntax, but I'm not sure that's actually 
> correct...).
> 
> I've therefore merged the "B" variant of my patch to emacs-30 (as commit 
> 130c3efa108) that checks for zero size on the file. I thought about it 
> and this way seemed safer, since I'm not sure what other scenarios might 
> signal a 'file-error', and I'd rather not suppress something I 
> shouldn't: better for a user to file another bug in that case so we can 
> evaluate it, I think.
> 
> Closing this bug now. (Though of course let me know if I've missed 
> anything here.)

Thanks, this is fine by me.




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.