From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Date: Thu, 20 Jun 2024 07:53:12 +0300 Message-ID: <86r0csnrk7.fsf@gnu.org> References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24092"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71655@debbugs.gnu.org, james@literate-devops.io To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 20 06:54:16 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sK9oN-00063Y-4K for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Jun 2024 06:54:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sK9o9-0007u9-6i; Thu, 20 Jun 2024 00:54:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sK9o7-0007tt-AS for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 00:53:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sK9o7-0001PJ-2X for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 00:53:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sK9oA-0000Jl-LG for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 00:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Jun 2024 04:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71655 X-GNU-PR-Package: emacs Original-Received: via spool by 71655-submit@debbugs.gnu.org id=B71655.17188592081162 (code B ref 71655); Thu, 20 Jun 2024 04:54:02 +0000 Original-Received: (at 71655) by debbugs.gnu.org; 20 Jun 2024 04:53:28 +0000 Original-Received: from localhost ([127.0.0.1]:43300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK9nb-0000If-DQ for submit@debbugs.gnu.org; Thu, 20 Jun 2024 00:53:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK9nY-0000IM-Qj for 71655@debbugs.gnu.org; Thu, 20 Jun 2024 00:53:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sK9nP-0001Lw-G8; Thu, 20 Jun 2024 00:53:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0TxGn8Pqokcgdz0HrJhsLOl1DK2SnADPRibkvDFWTJw=; b=dr5RCbm3DDcg OIqd4B0nd1vtabRVSHsWDBW7EKMHiICMo2InG0sIPC1U8/3v+Ul85k0coXPro1dNOA51BlO7tFlMp C0G/FtSiduw0hc9LLVnuu5vp58eG2daSFGjukgn2G1K0qbbLQSyjZQ1HK0T/Uf4VwD+qZeT90ukr1 Q1VBTIJ1C5n9PsF4evYSVOgbUK/JEqm3Akt9YBEI+38y4Q3eCmKKcXg27JozlVMGZjvnAkr+ZUMpo FnaYuoRgwwfT1y8ZzTZYGUQsfWJqiv60bjKQV1KExtcz1G/3zB9mGRd70VkW9s4QYS73u1llJq0fE qXcw4KRSg05XZuTTjsAt4A==; In-Reply-To: (message from Jim Porter on Wed, 19 Jun 2024 12:40:12 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287525 Archived-At: > Date: Wed, 19 Jun 2024 12:40:12 -0700 > Cc: 71655@debbugs.gnu.org, james@literate-devops.io > From: Jim Porter > > 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.