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 10:45:46 +0300 Message-ID: <86cyocnjkl.fsf@gnu.org> References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19604"; 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 09:47:17 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 1sKCVo-0004q3-RD for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Jun 2024 09:47:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKCVZ-0005im-1s; Thu, 20 Jun 2024 03:47: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 1sKCVY-0005id-0C for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 03:47:00 -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 1sKCVW-0006cE-MP for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 03:46:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKCVa-0000O5-B8 for bug-gnu-emacs@gnu.org; Thu, 20 Jun 2024 03:47: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 07:47: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.17188695631340 (code B ref 71655); Thu, 20 Jun 2024 07:47:02 +0000 Original-Received: (at 71655) by debbugs.gnu.org; 20 Jun 2024 07:46:03 +0000 Original-Received: from localhost ([127.0.0.1]:47358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKCUc-0000LX-RE for submit@debbugs.gnu.org; Thu, 20 Jun 2024 03:46:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKCUa-0000Km-QS for 71655@debbugs.gnu.org; Thu, 20 Jun 2024 03:46:01 -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 1sKCUR-0006Wj-EY; Thu, 20 Jun 2024 03:45:51 -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=0iZUND3Il0PEZUTGFfvtYrUheAPG3ni7zoch1z4IpoI=; b=B51RU0t02rnb VZ6AAMUn8tolTMc4DkFJoPrAu5N8ZoSs4Jy1DacsvPIOnlX+e5hzrOAlhgi/3BRdXIp04O78wgBPo nt1D+taeqvlkNG4ZkNhN8Vm54es7mhzvOWyVACP1oBsuxl0KE3EoXr8xiAZcRUrGDWox8zKGPv2Si QB17UGRA/9DSxpxw9zo8WLuVgx4yajmy4YmJh9YTPrUGy9+RsKilg+XC9j6gAoacnKykMo+cDy14U ZTIwfkv2cqmrSpCU6JUjK6tKpwcMraoLZCDCtxCzmejRMyUppjFQQ+5MhCAOE9v8Cn6ZatJhOehdR 2Ff+frX7rDKk42D1mOjz4g==; In-Reply-To: <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> (message from Jim Porter on Wed, 19 Jun 2024 22:34:02 -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:287534 Archived-At: > Date: Wed, 19 Jun 2024 22:34:02 -0700 > Cc: 71655@debbugs.gnu.org, james@literate-devops.io > From: Jim Porter > > 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 > >> > >> 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.