From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 14:49:17 2024 Received: (at submit) by debbugs.gnu.org; 19 Jun 2024 18:49:17 +0000 Received: from localhost ([127.0.0.1]:55034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0Mu-0003SE-6Q for submit@debbugs.gnu.org; Wed, 19 Jun 2024 14:49:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:51610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJxcx-0005k5-QV for submit@debbugs.gnu.org; Wed, 19 Jun 2024 11:53:40 -0400 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 1sJxct-0003xx-KQ for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 11:53:36 -0400 Received: from mail-40136.proton.ch ([185.70.40.136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJxcq-0002Vo-0L for bug-gnu-emacs@gnu.org; Wed, 19 Jun 2024 11:53:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=literate-devops.io; s=protonmail3; t=1718812401; x=1719071601; bh=b8wkmjw+xau6evkw4WMy2QuZB8l8+Go5pjoREjiTZtY=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=RwOlileGIRsj2jcNUHKbRZnw+mBq7TOu408mqmc7C/fR/QxZf7DD+MmydM9H3cwd4 z/eiWGczsKQzbkDJ4sFdYS/JNuqwLikb+ZzFjgSAYBK7hBXMFCpEODjj1kwE+fhvkF VJAgxuTUaZWzvqClla712ksEZRXpa+qu/2q8+d+VUTor1S96ozYDNlSil/HyQBVNqg ZGj/wb9cs+SooYkQNa+RAkZvvQvzcskwePVDnXBlTJCsnbAEcqU8dLj7RpnDPT86ld z18zCoB3Etgw0JcHzWXskPZgC9pmXMlo++zIbPHUnZMgx4ANr+8CQTtakXBL+blANE pVz2hZn38vyzg== Date: Wed, 19 Jun 2024 15:53:14 +0000 To: "bug-gnu-emacs@gnu.org" From: James Hilling Subject: Eshell external commands do not work under GNU Emacs for Windows Message-ID: Feedback-ID: 76906596:user:proton X-Pm-Message-ID: 9dbc0e6b4964a46e3e33b27bd77dca4d7e22f0a1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_xDw833S0ibX91pn7QyZ5hUymbjz8cm2dygkKK40YmP8" Received-SPF: pass client-ip=185.70.40.136; envelope-from=james@literate-devops.io; helo=mail-40136.proton.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 19 Jun 2024 14:49:14 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --b1_xDw833S0ibX91pn7QyZ5hUymbjz8cm2dygkKK40YmP8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgYWxsLAoKVGhlcmUgYXBwZWFycyB0byBiZSBhIHBvdGVudGlhbCBidWcgd2l0aCBFc2hlbGwg d2hlbiBydW5uaW5nIGV4dGVybmFsIGNvbW1hbmRzIG9uIEdOVSBFbWFjcyBmb3IgV2luZG93cywg aS5lLiBub3QgV1NML1dTTDIvQ3lnd2luLgoKVG8gcmVwcm9kdWNlOgoKU3RhcnQgRW1hY3Mgd2l0 aCAiLVEiLCBvcGVuIEVzaGVsbCB3aXRoIGBNLXggZXNoZWxsYCwgcnVuIGB3aW5nZXQuZXhlIC0t aGVscGAuCgooRXNoZWxsKSAkIHdpbmdldCAtLWhlbHAKCk9wZW5pbmcgaW5wdXQgZmlsZTogSW52 YWxpZCBhcmd1bWVudCwgQzovVXNlcnMvTXlVc2VyL0FwcERhdGEvTG9jYWwvTWljcm9zb2Z0L1dp bmRvd3NBcHBzL3dpbmdldC5leGUKCkZvciBzb21lIHJlYXNvbiBleHRlcm5hbCBjb21tYW5kcyBz dWNoIGFzIGB3aW5nZXQuZXhlYCBkbyBub3QgYXBwZWFyIHRvIGJlIHdvcmtpbmcgcHJvcGVybHku CgpJIHRob3VnaHQgdGhhdCBFc2hlbGwgbWF5IGJlIGhhdmluZyBpc3N1ZXMgd2hlbiByZWFkaW5n IGV4dGVybmFsIGNvbW1hbmQgYXJndW1lbnRzLCBidXQgcnVubmluZyBgd2luZ2V0LmV4ZWAgb24g aXRzIG93biAod2l0aCBubyBhcmd1bWVudHMpIGFsc28gcmV0dXJucyB0aGUgc2FtZSBlcnJvci4K CldoYXQgd29ya3M6CgpSdW5uaW5nIGB3aW5nZXQuZXhlIC0taGVscGAgZnJvbSB0aGUgaW5mZXJp b3Igc2hlbGwgd29ya3MuCgpSdW5uaW5nIGBjbWQuZXhlIC9jIHdpbmdldC5leGUgLS1oZWxwYCBm cm9tIEVzaGVsbCBhbHNvIHdvcmtzLgoKSXMgdGhpcyBhIHBhdGggcmVsYXRlZCBpc3N1ZT8KCihF c2hlbGwpICQgd2hpY2ggd2luZ2V0LmV4ZQoKQzovVXNlcnMvTXlVc2VyL0FwcERhdGEvTG9jYWwv TWljcm9zb2Z0L1dpbmRvd3NBcHBzL3dpbmdldC5leGUKCihFc2hlbGwpICQgYWRkcGF0aAoKYzov V2luZG93cy9zeXN0ZW0zMgpDOi9XaW5kb3dzCkM6L1dpbmRvd3MvU3lzdGVtMzIvV2JlbQpDOi9X aW5kb3dzL1N5c3RlbTMyL1dpbmRvd3NQb3dlclNoZWxsL3YxLjAvCkM6L1dpbmRvd3MvU3lzdGVt MzIvT3BlblNTSC8KQzovUHJvZ3JhbSBGaWxlcyAoeDg2KS9HcGc0d2luLy4uL0dudVBHL2JpbgpD Oi9Qcm9ncmFtIEZpbGVzL1B1VFRZLwpDOi9Vc2Vycy9NeVVzZXIvQXBwRGF0YS9Mb2NhbC9NaWNy b3NvZnQvV2luZG93c0FwcHMKLgpDOi9Vc2Vycy9NeVVzZXIvQXBwRGF0YS9Mb2NhbC9Qcm9ncmFt cy9vaC1teS1wb3NoL2JpbgoKRnJvbSB0aGUgYWJvdmUgb3V0cHV0LCBFc2hlbGwgYXBwZWFycyB0 byBiZSBhd2FyZSBvZiB0aGUgcGF0aCBhbmQgdGhlcmVmb3JlIHNob3VsZCBhbHNvIGJlIGFibGUg dG8gZXhlY3V0ZSBjb21tYW5kcyBzdWNoIGFzIGB3aW5nZXQuZXhlYC4KCkkgdHJpZWQgbGF1bmNo aW5nIG90aGVyIGV4ZWN1dGFibGVzIGZyb20gYEM6L1VzZXJzL015VXNlci9BcHBEYXRhL0xvY2Fs L01pY3Jvc29mdC9XaW5kb3dzQXBwcy9gIGJ1dCB0aGV5IGFsc28gZmFpbCBpbiB0aGUgZXhhY3Qg c2FtZSB3YXkuCgpPZGRseSBlbm91Z2gsIEkgY2FuIGV4ZWN1dGUgZXh0ZXJuYWwgY29tbWFuZHMg d2l0aGluIEVzaGVsbCBmb3IgZXhlY3V0YWJsZXMgdW5kZXIgYGM6L1dpbmRvd3Mvc3lzdGVtMzIv YCwgZS5nLiBJIGNhbiBleGVjdXRlIGBpcGNvbmZpZy5leGVgIGZyb20gRXNoZWxsIGFuZCBpdCB3 aWxsIHdvcmsganVzdCBmaW5lLiBTbyB0aGlzIGJ1ZyBkb2VzIG5vdCBhZmZlY3QgYWxsIGV4dGVy bmFsIGNvbW1hbmRzLgoKKEVzaGVsbCkgJCB3aGljaCBpcGNvbmZpZy5leGUKCmM6L1dpbmRvd3Mv c3lzdGVtMzIvaXBjb25maWcuZXhlCgpJIHRoZW4gdHJpZWQgcnVubmluZyBFbWFjcyBhcyBhbiBh ZG1pbmlzdHJhdG9yIChmb3IgdHJvdWJsZXNob290aW5nIHB1cnBvc2VzKSBidXQgdGhpcyBhbHNv IGdhdmUgbWUgdGhlIHNhbWUgZXJyb3Igd2hlbiByZXByb2R1Y2luZy4KCkRvZXMgYW55b25lIGtu b3cgb2YgYW55IEVtYWNzIGNvbmZpZ3VyYXRpb24gb3IgdmFyaWFibGVzIHRoYXQgd2lsbCBmaXgg dGhpcyBpc3N1ZT8gSSBjYW5ub3Qgc2VlbSB0byBmaW5kIGFueSBpbmZvcm1hdGlvbiBvbmxpbmUg bm9yIGFueSBoaW50cyBmcm9tIHRoZSBkb2NzIHRoYXQgd291bGQgaGVscCBtZSBzb2x2ZSB0aGlz IHByb2JsZW0uIFRoZXJlIGFsc28gZG9lc24ndCBhcHBlYXIgdG8gYmUgYW4gZXhpc3RpbmcgYnVn IG9uIHRoaXMgaXNzdWUuCgpLaW5kIHJlZ2FyZHMsCgpKYW1lcwoKQnVpbGQ6CgpJbiBHTlUgRW1h Y3MgMjkuMyAoYnVpbGQgMiwgeDg2XzY0LXc2NC1taW5ndzMyKSBvZiAyMDI0LTAzLTI0IGJ1aWx0 IG9uCkFWQUxPTgpXaW5kb3dpbmcgc3lzdGVtIGRpc3RyaWJ1dG9yICdNaWNyb3NvZnQgQ29ycC4n LCB2ZXJzaW9uIDEwLjAuMjI2MzEKU3lzdGVtIERlc2NyaXB0aW9uOiBNaWNyb3NvZnQgV2luZG93 cyAxMCBQcm8gKHYxMC4wLjIwMDkuMjI2MzEuMzczNykKCkNvbmZpZ3VyZWQgdXNpbmc6Cidjb25m aWd1cmUgLS13aXRoLW1vZHVsZXMgLS13aXRob3V0LWRidXMgLS13aXRoLW5hdGl2ZS1jb21waWxh dGlvbj1hb3QKLS13aXRob3V0LWNvbXByZXNzLWluc3RhbGwgLS13aXRoLXNxbGl0ZTMgLS13aXRo LXRyZWUtc2l0dGVyCkNGTEFHUz0tTzInCgpDb25maWd1cmVkIGZlYXR1cmVzOgpBQ0wgR0lGIEdN UCBHTlVUTFMgSEFSRkJVWlogSlBFRyBKU09OIExDTVMyIExJQlhNTDIgTU9EVUxFUyBOQVRJVkVf Q09NUApOT1RJRlkgVzMyTk9USUZZIFBEVU1QRVIgUE5HIFJTVkcgU09VTkQgU1FMSVRFMyBUSFJF QURTIFRJRkYKVE9PTEtJVF9TQ1JPTExfQkFSUyBUUkVFX1NJVFRFUiBXRUJQIFhQTSBaTElCCgoo TkFUSVZFX0NPTVAgcHJlc2VudCBidXQgbGliZ2Njaml0IG5vdCBhdmFpbGFibGUpCgpJbXBvcnRh bnQgc2V0dGluZ3M6CnZhbHVlIG9mICRMQU5HOiBFTkcKbG9jYWxlLWNvZGluZy1zeXN0ZW06IGNw MTI1MgoKTWFqb3IgbW9kZTogRXNoZWxsCgpNaW5vciBtb2RlcyBpbiBlZmZlY3Q6CnNoZWxsLWRp cnRyYWNrLW1vZGU6IHQKZXNoZWxsLXByb21wdC1tb2RlOiB0CmVzaGVsbC1oaXN0LW1vZGU6IHQK ZXNoZWxsLXByZWQtbW9kZTogdAplc2hlbGwtY21wbC1tb2RlOiB0CmVzaGVsbC1wcm9jLW1vZGU6 IHQKZXNoZWxsLWFyZy1tb2RlOiB0CnRvb2x0aXAtbW9kZTogdApnbG9iYWwtZWxkb2MtbW9kZTog dApzaG93LXBhcmVuLW1vZGU6IHQKZWxlY3RyaWMtaW5kZW50LW1vZGU6IHQKbW91c2Utd2hlZWwt bW9kZTogdAp0b29sLWJhci1tb2RlOiB0Cm1lbnUtYmFyLW1vZGU6IHQKZmlsZS1uYW1lLXNoYWRv dy1tb2RlOiB0Cmdsb2JhbC1mb250LWxvY2stbW9kZTogdApmb250LWxvY2stbW9kZTogdApibGlu ay1jdXJzb3ItbW9kZTogdApsaW5lLW51bWJlci1tb2RlOiB0CmluZGVudC10YWJzLW1vZGU6IHQK dHJhbnNpZW50LW1hcmstbW9kZTogdAphdXRvLWNvbXBvc2l0aW9uLW1vZGU6IHQKYXV0by1lbmNy eXB0aW9uLW1vZGU6IHQKYXV0by1jb21wcmVzc2lvbi1tb2RlOiB0CgpMb2FkLXBhdGggc2hhZG93 czoKTm9uZSBmb3VuZC4KCkZlYXR1cmVzOgooc2hhZG93IHNvcnQgbWFpbC1leHRyIGVtYWNzYnVn IG1lc3NhZ2UgbWFpbGNhcCB5YW5rLW1lZGlhIHB1bnkgZGlyZWQKZGlyZWQtbG9hZGRlZnMgcmZj ODIyIG1tbCBtbWwtc2VjIHBhc3N3b3JkLWNhY2hlIGVwYSBkZXJpdmVkIGVwZyByZmM2MDY4CmVw Zy1jb25maWcgZ251cy11dGlsIHRleHQtcHJvcGVydHktc2VhcmNoIG1tLWRlY29kZSBtbS1ib2Rp ZXMgbW0tZW5jb2RlCm1haWwtcGFyc2UgcmZjMjIzMSBtYWlsYWJicmV2IGdtbS11dGlscyBtYWls aGVhZGVyIHNlbmRtYWlsIHJmYzIwNDcKcmZjMjA0NSBpZXRmLWRydW1zIG1tLXV0aWwgbWFpbC1w cnN2ciBtYWlsLXV0aWxzIHRpbWUtZGF0ZSBjbC1zZXEKZW0tdW5peCBlbS10ZXJtIHRlcm0gc2hl bGwgc3Vici14IGVoZWxwIGVtLXNjcmlwdCBlbS1wcm9tcHQgZW0tbHMKZW0taGlzdCBlbS1wcmVk IGVtLWdsb2IgZW0tZXh0cGlwZSBlbS1jbXBsIGVtLWRpcnMgZXNoLXZhciBwY29tcGxldGUKY29t aW50IGFuc2ktb3NjIGFuc2ktY29sb3IgcmluZyBlbS1iYXNpYyBlbS1iYW5uZXIgZW0tYWxpYXMg ZXNoLW1vZGUKZXNoZWxsIGVzaC1jbWQgZ2VuZXJhdG9yIGNsLWxvYWRkZWZzIGNsLWxpYiBlc2gt ZXh0IGVzaC1vcHQgZXNoLXByb2MKZXNoLWlvIGVzaC1hcmcgZXNoLW1vZHVsZSBlc2gtZ3JvdXBz IGVzaC11dGlsIGZpbGVzLXggcm1jIGlzby10cmFuc2wKdG9vbHRpcCBjY29udiBlbGRvYyBwYXJl biBlbGVjdHJpYyB1bmlxdWlmeSBlZGlmZi1ob29rIHZjLWhvb2tzCmxpc3AtZmxvYXQtdHlwZSBl bGlzcC1tb2RlIG13aGVlbCBkb3MtdzMyIGxzLWxpc3AgZGlzcC10YWJsZQp0ZXJtL3czMi13aW4g dzMyLXdpbiB3MzItdmFycyB0ZXJtL2NvbW1vbi13aW4gdG9vbC1iYXIgZG5kIGZvbnRzZXQgaW1h Z2UKcmVnZXhwLW9wdCBmcmluZ2UgdGFidWxhdGVkLWxpc3QgcmVwbGFjZSBuZXdjb21tZW50IHRl eHQtbW9kZSBsaXNwLW1vZGUKcHJvZy1tb2RlIHJlZ2lzdGVyIHBhZ2UgdGFiLWJhciBtZW51LWJh ciByZm4tZXNoYWRvdyBpc2VhcmNoIGVhc3ltZW51CnRpbWVyIHNlbGVjdCBzY3JvbGwtYmFyIG1v dXNlIGppdC1sb2NrIGZvbnQtbG9jayBzeW50YXggZm9udC1jb3JlCnRlcm0vdHR5LWNvbG9ycyBm cmFtZSBtaW5pYnVmZmVyIG5hZHZpY2Ugc2VxIHNpbXBsZSBjbC1nZW5lcmljCmluZG9uZXNpYW4g cGhpbGlwcGluZSBjaGFtIGdlb3JnaWFuIHV0Zi04LWxhbmcgbWlzYy1sYW5nIHZpZXRuYW1lc2UK dGliZXRhbiB0aGFpIHRhaS12aWV0IGxhbyBrb3JlYW4gamFwYW5lc2UgZXVjanAtbXMgY3A1MTkz MiBoZWJyZXcgZ3JlZWsKcm9tYW5pYW4gc2xvdmFrIGN6ZWNoIGV1cm9wZWFuIGV0aGlvcGljIGlu ZGlhbiBjeXJpbGxpYyBjaGluZXNlCmNvbXBvc2l0ZSBlbW9qaS16d2ogY2hhcnNjcmlwdCBjaGFy cHJvcCBjYXNlLXRhYmxlIGVwYS1ob29rCmprYS1jbXByLWhvb2sgaGVscCBhYmJyZXYgb2JhcnJh eSBvY2xvc3VyZSBjbC1wcmVsb2FkZWQgYnV0dG9uIGxvYWRkZWZzCnRoZW1lLWxvYWRkZWZzIGZh Y2VzIGN1cy1mYWNlIG1hY3JvZXhwIGZpbGVzIHdpbmRvdyB0ZXh0LXByb3BlcnRpZXMKb3Zlcmxh eSBzaGExIG1kNSBiYXNlNjQgZm9ybWF0IGVudiBjb2RlLXBhZ2VzIG11bGUgY3VzdG9tIHdpZGdl dCBrZXltYXAKaGFzaHRhYmxlLXByaW50LXJlYWRhYmxlIGJhY2txdW90ZSB0aHJlYWRzIHczMm5v dGlmeSB3MzIgbGNtczIgbXVsdGktdHR5Cm1ha2UtbmV0d29yay1wcm9jZXNzIG5hdGl2ZS1jb21w aWxlIGVtYWNzKQoKTWVtb3J5IGluZm9ybWF0aW9uOgooKGNvbnNlcyAxNiA3NzkxNiAxMDM0NykK KHN5bWJvbHMgNDggNzI1OCAwKQooc3RyaW5ncyAzMiAyMjU1MiAxNTM1KQooc3RyaW5nLWJ5dGVz IDEgNjkyMDc3KQoodmVjdG9ycyAxNiAxNDc5NikKKHZlY3Rvci1zbG90cyA4IDMzODc2NCAxNTIx MikKKGZsb2F0cyA4IDQxIDMyKQooaW50ZXJ2YWxzIDU2IDM1NSAwKQooYnVmZmVycyA5ODQgMTEp KQ== --b1_xDw833S0ibX91pn7QyZ5hUymbjz8cm2dygkKK40YmP8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij48c3Bhbj5IaSBhbGwsPC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PHNwYW4+VGhlcmUgYXBwZWFycyB0byBiZSBhIHBvdGVudGlhbCBidWcgd2l0aCBFc2hlbGwg d2hlbiBydW5uaW5nIGV4dGVybmFsIGNvbW1hbmRzIG9uJm5ic3A7PHNwYW4+R05VIEVtYWNzIGZv ciBXaW5kb3dzPC9zcGFuPiwgaS5lLiBub3QgV1NML1dTTDIvQ3lnd2luLjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRvIHJlcHJvZHVjZTo8L2Rpdj48ZGl2 PjxzcGFuIHN0eWxlPSJzY3JvbGxiYXItd2lkdGg6dGhpbiI+PHNwYW4gc3R5bGU9InNjcm9sbGJh ci13aWR0aDp0aGluIj48YnI+PC9zcGFuPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJz Y3JvbGxiYXItd2lkdGg6dGhpbiI+PHNwYW4gc3R5bGU9InNjcm9sbGJhci13aWR0aDp0aGluIj48 YnI+PC9zcGFuPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJzY3JvbGxiYXItd2lkdGg6 dGhpbiI+PHNwYW4gc3R5bGU9InNjcm9sbGJhci13aWR0aDp0aGluIj5TdGFydCBFbWFjcyB3aXRo ICItUSIsIG9wZW4mbmJzcDs8L3NwYW4+PC9zcGFuPkVzaGVsbCB3aXRoIGBNLXggZXNoZWxsYCwg cnVuIGB3aW5nZXQuZXhlIC0taGVscGAuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj48c3Bhbj4oRXNoZWxsKSAkIHdpbmdldCAtLWhlbHA8L3NwYW4+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48c3Bhbj5PcGVuaW5nIGlucHV0IGZpbGU6IEludmFsaWQgYXJndW1lbnQs IEM6L1VzZXJzL015VXNlci9BcHBEYXRhL0xvY2FsL01pY3Jvc29mdC9XaW5kb3dzQXBwcy93aW5n ZXQuZXhlPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNw YW4gc3R5bGU9InNjcm9sbGJhci13aWR0aDp0aGluIj5Gb3Igc29tZSByZWFzb24gZXh0ZXJuYWwg Y29tbWFuZHMgc3VjaCBhcyBgd2luZ2V0LmV4ZWAgZG8gbm90IGFwcGVhciB0byBiZSB3b3JraW5n IHByb3Blcmx5Ljwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9InNjcm9sbGJhci13aWR0aDp0aGluIj48 L3NwYW4+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+SSB0aG91Z2h0IHRoYXQg RXNoZWxsIG1heSBiZSBoYXZpbmcgaXNzdWVzIHdoZW4gcmVhZGluZyBleHRlcm5hbCBjb21tYW5k IGFyZ3VtZW50cywgYnV0IHJ1bm5pbmcgYHdpbmdldC5leGVgIG9uIGl0cyBvd24gKHdpdGggbm8g YXJndW1lbnRzKSBhbHNvIHJldHVybnMgdGhlIHNhbWUgZXJyb3IuPC9zcGFuPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+V2hhdCB3b3Jrczo8L3NwYW4+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5SdW5uaW5nIGB3aW5n ZXQuZXhlIC0taGVscGAgZnJvbSB0aGUgaW5mZXJpb3Igc2hlbGwgd29ya3MuPC9zcGFuPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+UnVubmluZyBgY21kLmV4 ZSAvYyB3aW5nZXQuZXhlIC0taGVscGAgZnJvbSBFc2hlbGwgYWxzbyB3b3Jrcy48L3NwYW4+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5JcyB0aGlzIGEgcGF0 aCByZWxhdGVkIGlzc3VlPzwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PjxzcGFuPihFc2hlbGwpICQgd2hpY2ggd2luZ2V0LmV4ZTwvc3Bhbj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkM6L1VzZXJzL015VXNlci9BcHBEYXRhL0xvY2FsL01pY3Jv c29mdC9XaW5kb3dzQXBwcy93aW5nZXQuZXhlPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+KEVzaGVsbCkgJCBhZGRwYXRoPC9zcGFuPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+YzovV2luZG93cy9zeXN0ZW0zMjwvc3Bhbj48L2Rpdj48 ZGl2PjxzcGFuPkM6L1dpbmRvd3M8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5DOi9XaW5kb3dzL1N5 c3RlbTMyL1diZW08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5DOi9XaW5kb3dzL1N5c3RlbTMyL1dp bmRvd3NQb3dlclNoZWxsL3YxLjAvPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+QzovV2luZG93cy9T eXN0ZW0zMi9PcGVuU1NILzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkM6L1Byb2dyYW0gRmlsZXMg KHg4NikvR3BnNHdpbi8uLi9HbnVQRy9iaW48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5DOi9Qcm9n cmFtIEZpbGVzL1B1VFRZLzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkM6L1VzZXJzL015VXNlci9B cHBEYXRhL0xvY2FsL01pY3Jvc29mdC9XaW5kb3dzQXBwczwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu Pi48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5DOi9Vc2Vycy9NeVVzZXIvQXBwRGF0YS9Mb2NhbC9Q cm9ncmFtcy9vaC1teS1wb3NoL2Jpbjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PjxzcGFuPkZyb20gdGhlIGFib3ZlIG91dHB1dCwgRXNoZWxsIGFwcGVhcnMg dG8gYmUgYXdhcmUgb2YgdGhlIHBhdGggYW5kIHRoZXJlZm9yZSBzaG91bGQgYWxzbyBiZSBhYmxl IHRvIGV4ZWN1dGUgY29tbWFuZHMgc3VjaCBhcyBgd2luZ2V0LmV4ZWAuPC9zcGFuPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+SSB0cmllZCBsYXVuY2hpbmcg b3RoZXIgZXhlY3V0YWJsZXMgZnJvbSBgQzovVXNlcnMvTXlVc2VyL0FwcERhdGEvTG9jYWwvTWlj cm9zb2Z0L1dpbmRvd3NBcHBzL2AgYnV0IHRoZXkgYWxzbyBmYWlsIGluIHRoZSBleGFjdCBzYW1l IHdheS48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bh bj5PZGRseSBlbm91Z2gsIEkgY2FuIGV4ZWN1dGUgZXh0ZXJuYWwgY29tbWFuZHMgd2l0aGluIEVz aGVsbCBmb3ImbmJzcDs8L3NwYW4+ZXhlY3V0YWJsZXMgdW5kZXIgYGM6L1dpbmRvd3Mvc3lzdGVt MzIvYCwgZS5nLiBJIGNhbiBleGVjdXRlIGBpcGNvbmZpZy5leGVgIGZyb20gRXNoZWxsIGFuZCBp dCB3aWxsIHdvcmsganVzdCBmaW5lLiBTbyB0aGlzIGJ1ZyBkb2VzIG5vdCBhZmZlY3QgYWxsIGV4 dGVybmFsIGNvbW1hbmRzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PHNwYW4+KEVzaGVsbCkgJCB3aGljaCBpcGNvbmZpZy5leGU8L3NwYW4+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48c3Bhbj5jOi9XaW5kb3dzL3N5c3RlbTMyL2lwY29uZmlnLmV4ZTwvc3Bhbj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkkgdGhlbiB0cmll ZCBydW5uaW5nIEVtYWNzIGFzIGFuIGFkbWluaXN0cmF0b3IgKGZvciB0cm91Ymxlc2hvb3Rpbmcg cHVycG9zZXMpJm5ic3A7PC9zcGFuPmJ1dCB0aGlzIGFsc28gZ2F2ZSBtZSB0aGUgc2FtZSBlcnJv ciB3aGVuIHJlcHJvZHVjaW5nLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PHNwYW4+RG9lcyBhbnlvbmUga25vdyBvZiBhbnkgRW1hY3MgY29uZmlndXJhdGlvbiBvciB2 YXJpYWJsZXMgdGhhdCB3aWxsJm5ic3A7PC9zcGFuPmZpeCB0aGlzIGlzc3VlPyAmbmJzcDtJIGNh bm5vdCBzZWVtIHRvIGZpbmQgYW55IGluZm9ybWF0aW9uIG9ubGluZSBub3IgYW55IGhpbnRzIGZy b20gdGhlIGRvY3MgdGhhdCB3b3VsZCBoZWxwIG1lIHNvbHZlIHRoaXMgcHJvYmxlbS4gVGhlcmUg YWxzbyBkb2Vzbid0IGFwcGVhciB0byBiZSBhbiBleGlzdGluZyBidWcgb24gdGhpcyBpc3N1ZS48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPktpbmQgcmVnYXJk cyw8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5K YW1lczwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFu PkJ1aWxkOjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkluIEdOVSBFbWFj cyAyOS4zIChidWlsZCAyLCB4ODZfNjQtdzY0LW1pbmd3MzIpIG9mIDIwMjQtMDMtMjQgYnVpbHQg b248L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDtBVkFMT048L3NwYW4+PC9kaXY+PGRpdj48 c3Bhbj5XaW5kb3dpbmcgc3lzdGVtIGRpc3RyaWJ1dG9yICdNaWNyb3NvZnQgQ29ycC4nLCB2ZXJz aW9uIDEwLjAuMjI2MzE8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5TeXN0ZW0gRGVzY3JpcHRpb246 IE1pY3Jvc29mdCBXaW5kb3dzIDEwIFBybyAodjEwLjAuMjAwOS4yMjYzMS4zNzM3KTwvc3Bhbj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkNvbmZpZ3VyZWQgdXNpbmc6PC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+Jm5ic3A7J2NvbmZpZ3VyZSAtLXdpdGgtbW9kdWxlcyAtLXdpdGhvdXQt ZGJ1cyAtLXdpdGgtbmF0aXZlLWNvbXBpbGF0aW9uPWFvdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu PiZuYnNwOy0td2l0aG91dC1jb21wcmVzcy1pbnN0YWxsIC0td2l0aC1zcWxpdGUzIC0td2l0aC10 cmVlLXNpdHRlcjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwO0NGTEFHUz0tTzInPC9zcGFu PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+Q29uZmlndXJlZCBmZWF0dXJlczo8L3Nw YW4+PC9kaXY+PGRpdj48c3Bhbj5BQ0wgR0lGIEdNUCBHTlVUTFMgSEFSRkJVWlogSlBFRyBKU09O IExDTVMyIExJQlhNTDIgTU9EVUxFUyBOQVRJVkVfQ09NUDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu Pk5PVElGWSBXMzJOT1RJRlkgUERVTVBFUiBQTkcgUlNWRyBTT1VORCBTUUxJVEUzIFRIUkVBRFMg VElGRjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPlRPT0xLSVRfU0NST0xMX0JBUlMgVFJFRV9TSVRU RVIgV0VCUCBYUE0gWkxJQjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPihO QVRJVkVfQ09NUCBwcmVzZW50IGJ1dCBsaWJnY2NqaXQgbm90IGF2YWlsYWJsZSk8L3NwYW4+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5JbXBvcnRhbnQgc2V0dGluZ3M6PC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IHZhbHVlIG9mICRMQU5HOiBFTkc8L3NwYW4+PC9kaXY+PGRp dj48c3Bhbj4mbmJzcDsgbG9jYWxlLWNvZGluZy1zeXN0ZW06IGNwMTI1Mjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPk1ham9yIG1vZGU6IEVzaGVsbDwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPk1pbm9yIG1vZGVzIGluIGVmZmVjdDo8L3NwYW4+PC9k aXY+PGRpdj48c3Bhbj4mbmJzcDsgc2hlbGwtZGlydHJhY2stbW9kZTogdDwvc3Bhbj48L2Rpdj48 ZGl2PjxzcGFuPiZuYnNwOyBlc2hlbGwtcHJvbXB0LW1vZGU6IHQ8L3NwYW4+PC9kaXY+PGRpdj48 c3Bhbj4mbmJzcDsgZXNoZWxsLWhpc3QtbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZu YnNwOyBlc2hlbGwtcHJlZC1tb2RlOiB0PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IGVz aGVsbC1jbXBsLW1vZGU6IHQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsgZXNoZWxsLXBy b2MtbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyBlc2hlbGwtYXJnLW1vZGU6 IHQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsgdG9vbHRpcC1tb2RlOiB0PC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IGdsb2JhbC1lbGRvYy1tb2RlOiB0PC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+Jm5ic3A7IHNob3ctcGFyZW4tbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu PiZuYnNwOyBlbGVjdHJpYy1pbmRlbnQtbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZu YnNwOyBtb3VzZS13aGVlbC1tb2RlOiB0PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IHRv b2wtYmFyLW1vZGU6IHQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsgbWVudS1iYXItbW9k ZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyBmaWxlLW5hbWUtc2hhZG93LW1vZGU6 IHQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsgZ2xvYmFsLWZvbnQtbG9jay1tb2RlOiB0 PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IGZvbnQtbG9jay1tb2RlOiB0PC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IGJsaW5rLWN1cnNvci1tb2RlOiB0PC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+Jm5ic3A7IGxpbmUtbnVtYmVyLW1vZGU6IHQ8L3NwYW4+PC9kaXY+PGRpdj48c3Bh bj4mbmJzcDsgaW5kZW50LXRhYnMtbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNw OyB0cmFuc2llbnQtbWFyay1tb2RlOiB0PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7IGF1 dG8tY29tcG9zaXRpb24tbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyBhdXRv LWVuY3J5cHRpb24tbW9kZTogdDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyBhdXRvLWNv bXByZXNzaW9uLW1vZGU6IHQ8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5M b2FkLXBhdGggc2hhZG93czo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5Ob25lIGZvdW5kLjwvc3Bh bj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkZlYXR1cmVzOjwvc3Bhbj48L2Rpdj48 ZGl2PjxzcGFuPihzaGFkb3cgc29ydCBtYWlsLWV4dHIgZW1hY3NidWcgbWVzc2FnZSBtYWlsY2Fw IHlhbmstbWVkaWEgcHVueSBkaXJlZDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmRpcmVkLWxvYWRk ZWZzIHJmYzgyMiBtbWwgbW1sLXNlYyBwYXNzd29yZC1jYWNoZSBlcGEgZGVyaXZlZCBlcGcgcmZj NjA2ODwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmVwZy1jb25maWcgZ251cy11dGlsIHRleHQtcHJv cGVydHktc2VhcmNoIG1tLWRlY29kZSBtbS1ib2RpZXMgbW0tZW5jb2RlPC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4+bWFpbC1wYXJzZSByZmMyMjMxIG1haWxhYmJyZXYgZ21tLXV0aWxzIG1haWxoZWFk ZXIgc2VuZG1haWwgcmZjMjA0Nzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPnJmYzIwNDUgaWV0Zi1k cnVtcyBtbS11dGlsIG1haWwtcHJzdnIgbWFpbC11dGlscyB0aW1lLWRhdGUgY2wtc2VxPC9zcGFu PjwvZGl2PjxkaXY+PHNwYW4+ZW0tdW5peCBlbS10ZXJtIHRlcm0gc2hlbGwgc3Vici14IGVoZWxw IGVtLXNjcmlwdCBlbS1wcm9tcHQgZW0tbHM8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5lbS1oaXN0 IGVtLXByZWQgZW0tZ2xvYiBlbS1leHRwaXBlIGVtLWNtcGwgZW0tZGlycyBlc2gtdmFyIHBjb21w bGV0ZTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmNvbWludCBhbnNpLW9zYyBhbnNpLWNvbG9yIHJp bmcgZW0tYmFzaWMgZW0tYmFubmVyIGVtLWFsaWFzIGVzaC1tb2RlPC9zcGFuPjwvZGl2PjxkaXY+ PHNwYW4+ZXNoZWxsIGVzaC1jbWQgZ2VuZXJhdG9yIGNsLWxvYWRkZWZzIGNsLWxpYiBlc2gtZXh0 IGVzaC1vcHQgZXNoLXByb2M8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5lc2gtaW8gZXNoLWFyZyBl c2gtbW9kdWxlIGVzaC1ncm91cHMgZXNoLXV0aWwgZmlsZXMteCBybWMgaXNvLXRyYW5zbDwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuPnRvb2x0aXAgY2NvbnYgZWxkb2MgcGFyZW4gZWxlY3RyaWMgdW5p cXVpZnkgZWRpZmYtaG9vayB2Yy1ob29rczwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmxpc3AtZmxv YXQtdHlwZSBlbGlzcC1tb2RlIG13aGVlbCBkb3MtdzMyIGxzLWxpc3AgZGlzcC10YWJsZTwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuPnRlcm0vdzMyLXdpbiB3MzItd2luIHczMi12YXJzIHRlcm0vY29t bW9uLXdpbiB0b29sLWJhciBkbmQgZm9udHNldCBpbWFnZTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFu PnJlZ2V4cC1vcHQgZnJpbmdlIHRhYnVsYXRlZC1saXN0IHJlcGxhY2UgbmV3Y29tbWVudCB0ZXh0 LW1vZGUgbGlzcC1tb2RlPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+cHJvZy1tb2RlIHJlZ2lzdGVy IHBhZ2UgdGFiLWJhciBtZW51LWJhciByZm4tZXNoYWRvdyBpc2VhcmNoIGVhc3ltZW51PC9zcGFu PjwvZGl2PjxkaXY+PHNwYW4+dGltZXIgc2VsZWN0IHNjcm9sbC1iYXIgbW91c2Ugaml0LWxvY2sg Zm9udC1sb2NrIHN5bnRheCBmb250LWNvcmU8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj50ZXJtL3R0 eS1jb2xvcnMgZnJhbWUgbWluaWJ1ZmZlciBuYWR2aWNlIHNlcSBzaW1wbGUgY2wtZ2VuZXJpYzwv c3Bhbj48L2Rpdj48ZGl2PjxzcGFuPmluZG9uZXNpYW4gcGhpbGlwcGluZSBjaGFtIGdlb3JnaWFu IHV0Zi04LWxhbmcgbWlzYy1sYW5nIHZpZXRuYW1lc2U8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj50 aWJldGFuIHRoYWkgdGFpLXZpZXQgbGFvIGtvcmVhbiBqYXBhbmVzZSBldWNqcC1tcyBjcDUxOTMy IGhlYnJldyBncmVlazwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPnJvbWFuaWFuIHNsb3ZhayBjemVj aCBldXJvcGVhbiBldGhpb3BpYyBpbmRpYW4gY3lyaWxsaWMgY2hpbmVzZTwvc3Bhbj48L2Rpdj48 ZGl2PjxzcGFuPmNvbXBvc2l0ZSBlbW9qaS16d2ogY2hhcnNjcmlwdCBjaGFycHJvcCBjYXNlLXRh YmxlIGVwYS1ob29rPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+amthLWNtcHItaG9vayBoZWxwIGFi YnJldiBvYmFycmF5IG9jbG9zdXJlIGNsLXByZWxvYWRlZCBidXR0b24gbG9hZGRlZnM8L3NwYW4+ PC9kaXY+PGRpdj48c3Bhbj50aGVtZS1sb2FkZGVmcyBmYWNlcyBjdXMtZmFjZSBtYWNyb2V4cCBm aWxlcyB3aW5kb3cgdGV4dC1wcm9wZXJ0aWVzPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+b3Zlcmxh eSBzaGExIG1kNSBiYXNlNjQgZm9ybWF0IGVudiBjb2RlLXBhZ2VzIG11bGUgY3VzdG9tIHdpZGdl dCBrZXltYXA8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5oYXNodGFibGUtcHJpbnQtcmVhZGFibGUg YmFja3F1b3RlIHRocmVhZHMgdzMybm90aWZ5IHczMiBsY21zMiBtdWx0aS10dHk8L3NwYW4+PC9k aXY+PGRpdj48c3Bhbj5tYWtlLW5ldHdvcmstcHJvY2VzcyBuYXRpdmUtY29tcGlsZSBlbWFjcyk8 L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5NZW1vcnkgaW5mb3JtYXRpb246 PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+KChjb25zZXMgMTYgNzc5MTYgMTAzNDcpPC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+Jm5ic3A7KHN5bWJvbHMgNDggNzI1OCAwKTwvc3Bhbj48L2Rpdj48ZGl2 PjxzcGFuPiZuYnNwOyhzdHJpbmdzIDMyIDIyNTUyIDE1MzUpPC9zcGFuPjwvZGl2PjxkaXY+PHNw YW4+Jm5ic3A7KHN0cmluZy1ieXRlcyAxIDY5MjA3Nyk8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4m bmJzcDsodmVjdG9ycyAxNiAxNDc5Nik8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsodmVj dG9yLXNsb3RzIDggMzM4NzY0IDE1MjEyKTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyhm bG9hdHMgOCA0MSAzMik8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsoaW50ZXJ2YWxzIDU2 IDM1NSAwKTwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyhidWZmZXJzIDk4NCAxMSkpPC9z cGFuPjwvZGl2PjxzcGFuPjwvc3Bhbj48YnI+PC9kaXY+DQo8ZGl2IGNsYXNzPSJwcm90b25tYWls X3NpZ25hdHVyZV9ibG9jayBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQogICAg PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciBwcm90b25tYWlsX3Np Z25hdHVyZV9ibG9jay1lbXB0eSI+DQogICAgICAgIA0KICAgICAgICAgICAgPC9kaXY+DQogICAg DQogICAgICAgICAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90 b24gcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPg0KICAgICAgICANCiAgICAgICAg ICAgIDwvZGl2Pg0KPC9kaXY+DQo= --b1_xDw833S0ibX91pn7QyZ5hUymbjz8cm2dygkKK40YmP8-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 15:12:56 2024 Received: (at 71655) by debbugs.gnu.org; 19 Jun 2024 19:12:56 +0000 Received: from localhost ([127.0.0.1]:55713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0ji-0004Lz-4k for submit@debbugs.gnu.org; Wed, 19 Jun 2024 15:12:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0jg-0004Lh-1p for 71655@debbugs.gnu.org; Wed, 19 Jun 2024 15:12:49 -0400 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 1sK0jW-0007sc-EV; Wed, 19 Jun 2024 15:12:38 -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=1EImajEAliPpRdgG22RRXA0exEvMy0cqYLr4DOvDGfY=; b=M2jn6pZGeXaU KEQqEZlmcHhCQ5LIR3Vn46reT9U8+C7UNkCUOAEKGMmrObk2DuzmzVFvUxak59NQoR+pe6yPVlgvt hQ3xxJUnj1kltTUQJYr2EeRXVTrXWUfuSWZ6wFqsIzBWrXAq2J1eaxUo+zrD4JImFlcdorFaflAeF U2mw/IdAri5VFK6oLxzl/zX87MvslMhnWh3dcV1FWfG/HrSsiSSzkSO0VNdimCAKXdjDoxaClWASD 5mWqxF4HvoLIVsvsqFHEVuSGgF54aiipwkdbcLoxfV03T8j9qiyqrXoYNkMZYBUIB4OW33Nsc1mmB 77Ue6pMz8T4XL91JGnkXrQ==; Date: Wed, 19 Jun 2024 22:12:34 +0300 Message-Id: <86y170oifx.fsf@gnu.org> From: Eli Zaretskii To: James Hilling In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 19 Jun 2024 15:53:14 +0000 > From: James Hilling via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > There appears to be a potential bug with Eshell when running external commands on GNU Emacs for > Windows, i.e. not WSL/WSL2/Cygwin. I don't think this has anything to do with Eshell. Or Emacs, for that matter. See below. > To reproduce: > > Start Emacs with "-Q", open Eshell with `M-x eshell`, run `winget.exe --help`. > > (Eshell) $ winget --help > > Opening input file: Invalid argument, C:/Users/MyUser/AppData/Local/Microsoft/WindowsApps/winget.exe > > For some reason external commands such as `winget.exe` do not appear to be working properly. Try (Eshell) $ ls -l C:/Users/MyUser/AppData/Local/Microsoft/WindowsApps/winget.exe What do you see? Does what you see explain the error? I think this page explains what is going on: https://stackoverflow.com/questions/58296925/what-is-zero-byte-executable-files-in-windows From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 15:23:14 2024 Received: (at 71655) by debbugs.gnu.org; 19 Jun 2024 19:23:14 +0000 Received: from localhost ([127.0.0.1]:55986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0tl-0004hJ-Tp for submit@debbugs.gnu.org; Wed, 19 Jun 2024 15:23:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0tj-0004h4-58 for 71655@debbugs.gnu.org; Wed, 19 Jun 2024 15:23:12 -0400 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 1sK0ta-0001By-50; Wed, 19 Jun 2024 15:23:02 -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=cEapNk13+5TnRByDwAPwb5e9v2yh7nMl8DriVLMND8Y=; b=HjWPadIEwrBT MrJWFw+5ZRpjvShte827f/yTYLesmuCKwr8l4SocDig9W4rG8rqUO/RIHeNY5HaVerPSDwzoT7iH4 uxI8Gt+ZOIOmsWW39GX8b8/vM1dzWdEqxNq0npWs0JYfzwW4IoKJ4NUsiFfjoSZbyzOK3VGm80vX+ HHiOQZHEiC4huZeOGPta6Pz28o7WBovR62qSWXdXXPBWKSo0Jhts+T83Uodvv2Sexq3z4y5rkIuI1 WP9QaHEN6EH060dUsKiDk5KDPFh6/cw4yMIPG35GI1XDYhDam0fA1RJtlLJUxPBPdpoSmigUYk36I IXS+kR+LCV6z529czmCj/A==; Date: Wed, 19 Jun 2024 22:22:57 +0300 Message-Id: <86v824ohym.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: <86y170oifx.fsf@gnu.org> (message from Eli Zaretskii on Wed, 19 Jun 2024 22:12:34 +0300) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 71655@debbugs.gnu.org > Date: Wed, 19 Jun 2024 22:12:34 +0300 > From: Eli Zaretskii > > (Eshell) $ ls -l C:/Users/MyUser/AppData/Local/Microsoft/WindowsApps/winget.exe > > What do you see? Does what you see explain the error? > > I think this page explains what is going on: > > https://stackoverflow.com/questions/58296925/what-is-zero-byte-executable-files-in-windows That being said, both M-! and call-process succeed in invoking this "program" okay, so there's something Eshell does that gets in the way. Here's the backtrace from the error: Debugger entered--Lisp error: (file-error "Opening input file" "Invalid argument" "C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe") insert-file-contents("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe" nil 0 256 nil) insert-file-contents-literally("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe" nil 0 256) eshell-script-interpreter("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe") eshell-find-interpreter("winget" ("--help") nil) eshell-connection-local-command("winget" ("--help")) eshell-external-command("winget" ("--help")) eshell-plain-command("winget" ("--help")) eshell-named-command("winget" ("--help")) eval((eshell-named-command '"winget" '("--help"))) eshell-do-eval((eshell-named-command '"winget" '("--help")) nil) eshell-do-eval((unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook)) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #))) eval((let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-this-command-hook '(ignore))) (unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook))) nil) (condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '(ignore))) (unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))) eshell-do-eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) nil) eshell-do-eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-current-handles '[nil (((t) . 2) t) (((t) . 2) t)])) (funcall '#f(compiled-function () #))) eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)])) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)])) (condition-case err (eshell-do-eval '(let ((eshell-this-command-hook ...)) (unwind-protect (eshell-named-command ... ...) (mapc ... eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))) nil) eshell-do-eval((progn (let ((eshell-current-handles '[nil (... t) (... t)])) (condition-case err (eshell-do-eval '(let (...) (unwind-protect ... ...)) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))) nil) eshell-do-eval((unwind-protect (progn (let ((eshell-current-handles '[nil ... ...])) (condition-case err (eshell-do-eval '(let ... ...) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))) (run-hooks 'eshell-post-command-hook)) nil) eshell-do-eval((progn 'nil (unwind-protect (progn (let ((eshell-current-handles '...)) (condition-case err (eshell-do-eval '... nil) ((debug error) (eshell-errorn ...) (eshell-close-handles 1))))) (run-hooks 'eshell-post-command-hook))) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-current-handles '[nil (((t) . 2) t) (((t) . 2) t)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #))) eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let ((eshell-current-handles ...)) (condition-case err (eshell-do-eval ... nil) (... ... ...)))) (run-hooks 'eshell-post-command-hook))))) eshell-resume-eval((nil (let ((eshell-current-handles '[nil (... t) (... t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let (...) (condition-case err ... ...))) (run-hooks 'eshell-post-command-hook)))) nil)) eshell-eval-command((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let ((eshell-current-handles ...)) (condition-case err (eshell-do-eval ... nil) (... ... ...)))) (run-hooks 'eshell-post-command-hook)))) "winget --help") eshell-send-input(nil) funcall-interactively(eshell-send-input nil) call-interactively(eshell-send-input nil nil) command-execute(eshell-send-input) 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 15:30:17 2024 Received: (at 71655) by debbugs.gnu.org; 19 Jun 2024 19:30:18 +0000 Received: from localhost ([127.0.0.1]:56172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK10b-0004wu-7L for submit@debbugs.gnu.org; Wed, 19 Jun 2024 15:30:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK10Y-0004wc-Vh for 71655@debbugs.gnu.org; Wed, 19 Jun 2024 15:30:15 -0400 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 1sK10Q-0002cS-7c; Wed, 19 Jun 2024 15:30:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ZL6xzqOaR3VhORPCcX5hyz4FhvkEJ8L8WUrVbRg91Ww=; b=ApxQJdBYhNsku6udvYEj IKce/U7un9r1SUF4qaWZFSQdJUGY/0e1zEMtye1qDELWF/jqHfw4wUkrNXpD4gujnZuzxB25Saqmd 2bAh9pgyJZ+tF0JU4mw1TSW7stLvry3o8HiM7f0ds5Pxtx4LFzOgzCJMoEmNJokgwq6aDjUcBMYoq V46ra/EgRUMhDsOrf/pH0UsbSqh6oR6JAhvY+NIGQQd9XPFP2nTtl5GCsQYt7Vme2FEy5Z2mOB46g 6BRnlwwopfqTO2LCgQNaXk3kOzroFtU1yColVkdqlO2eQSxHC/EeMUZRmhvoF5g/cBQqtf6c52KpM 4e3Jv3Qtpq0fYA==; Date: Wed, 19 Jun 2024 22:30:00 +0300 Message-Id: <86tthoohmv.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: <86y170oifx.fsf@gnu.org> (message from Eli Zaretskii on Wed, 19 Jun 2024 22:12:34 +0300) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 71655@debbugs.gnu.org > Date: Wed, 19 Jun 2024 22:12:34 +0300 > From: Eli Zaretskii > > (Eshell) $ ls -l C:/Users/MyUser/AppData/Local/Microsoft/WindowsApps/winget.exe > > What do you see? Does what you see explain the error? > > I think this page explains what is going on: > > https://stackoverflow.com/questions/58296925/what-is-zero-byte-executable-files-in-windows That being said, both M-! and call-process succeed in invoking this "program" okay, so there's something Eshell does that gets in the way. Here's the backtrace from the error: Debugger entered--Lisp error: (file-error "Opening input file" "Invalid argument" "C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe") insert-file-contents("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe" nil 0 256 nil) insert-file-contents-literally("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe" nil 0 256) eshell-script-interpreter("C:/Users/EliZ/AppData/Local/Microsoft/WindowsApps/winget.exe") eshell-find-interpreter("winget" ("--help") nil) eshell-connection-local-command("winget" ("--help")) eshell-external-command("winget" ("--help")) eshell-plain-command("winget" ("--help")) eshell-named-command("winget" ("--help")) eval((eshell-named-command '"winget" '("--help"))) eshell-do-eval((eshell-named-command '"winget" '("--help")) nil) eshell-do-eval((unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook)) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #))) eval((let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-this-command-hook '(ignore))) (unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook))) nil) (condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '(ignore))) (unwind-protect (eshell-named-command '"winget" '("--help")) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))) eshell-do-eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) nil) eshell-do-eval((condition-case err (eshell-do-eval '(let ((eshell-this-command-hook '...)) (unwind-protect (eshell-named-command '"winget" '...) (mapc #'funcall eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-current-handles '[nil (((t) . 2) t) (((t) . 2) t)])) (funcall '#f(compiled-function () #))) eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)])) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)])) (condition-case err (eshell-do-eval '(let ((eshell-this-command-hook ...)) (unwind-protect (eshell-named-command ... ...) (mapc ... eshell-this-command-hook))) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))) nil) eshell-do-eval((progn (let ((eshell-current-handles '[nil (... t) (... t)])) (condition-case err (eshell-do-eval '(let (...) (unwind-protect ... ...)) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))) nil) eshell-do-eval((unwind-protect (progn (let ((eshell-current-handles '[nil ... ...])) (condition-case err (eshell-do-eval '(let ... ...) nil) ((debug error) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))) (run-hooks 'eshell-post-command-hook)) nil) eshell-do-eval((progn 'nil (unwind-protect (progn (let ((eshell-current-handles '...)) (condition-case err (eshell-do-eval '... nil) ((debug error) (eshell-errorn ...) (eshell-close-handles 1))))) (run-hooks 'eshell-post-command-hook))) nil) #f(compiled-function () #)() funcall(#f(compiled-function () #)) (let ((eshell-current-handles '[nil (((t) . 2) t) (((t) . 2) t)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #))) eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #)))) eshell-do-eval((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let ((eshell-current-handles ...)) (condition-case err (eshell-do-eval ... nil) (... ... ...)))) (run-hooks 'eshell-post-command-hook))))) eshell-resume-eval((nil (let ((eshell-current-handles '[nil (... t) (... t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let (...) (condition-case err ... ...))) (run-hooks 'eshell-post-command-hook)))) nil)) eshell-eval-command((let ((eshell-current-handles '[nil ((... . 2) t) ((... . 2) t)]) eshell-current-subjob-p) (progn 'nil (unwind-protect (progn (let ((eshell-current-handles ...)) (condition-case err (eshell-do-eval ... nil) (... ... ...)))) (run-hooks 'eshell-post-command-hook)))) "winget --help") eshell-send-input(nil) funcall-interactively(eshell-send-input nil) call-interactively(eshell-send-input nil nil) command-execute(eshell-send-input) 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? This naïve patch fixes the problem: diff --git a/lisp/eshell/esh-ext.el b/lisp/eshell/esh-ext.el index 3c4deb3..d9631be 100644 --- a/lisp/eshell/esh-ext.el +++ b/lisp/eshell/esh-ext.el @@ -247,7 +247,8 @@ eshell-connection-local-command ;; know the interpreter in that case, therefore the ;; check is suppressed. (or (and (stringp command) (file-remote-p command)) - (file-remote-p default-directory))))) + (file-remote-p default-directory) + (zerop (file-attribute-size (file-attributes (executable-find command)))))))) (cl-assert interp) (if (functionp (car interp)) (apply (car interp) (append (cdr interp) args)) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 15:41:25 2024 Received: (at 71655) by debbugs.gnu.org; 19 Jun 2024 19:41:25 +0000 Received: from localhost ([127.0.0.1]:56548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK1BN-0005JO-Eb for submit@debbugs.gnu.org; Wed, 19 Jun 2024 15:41:25 -0400 Received: from mail-pl1-f169.google.com ([209.85.214.169]:44379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK1BL-0005J7-4A for 71655@debbugs.gnu.org; Wed, 19 Jun 2024 15:41:23 -0400 Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1f9c2847618so1194385ad.1 for <71655@debbugs.gnu.org>; Wed, 19 Jun 2024 12:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718826014; x=1719430814; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=CK8hz4LxEC8FEUSar0dSbTbJ1JKQi4AD6vWGMU0oeJs=; b=DSgyMdDwJa0/X3y2NdleD7GdvXwKQSFe5Md625ZaFtQeJao+X7VBa8I8FxJa8ukTvW QcKrt6X8nCcK5CRxymkojpxPBzK5yFtkKfmGssxSyZTrXJeqze314xz0/mOZRr9YFj0R 7cec3jUoF4REQsbhxJo9znECksYeI51mOF/OW9faHbMM4FZ1Qs9DMa0yjDD/FMCO4k8g V4vFA6RWbiSSKnFAnkf4gicQtXVTYYlcxKZP5e04ga1tZhOmrdByEVwQpXcLUcY/QYtJ Ggrr13S8TCEIbPGktwHxpjR1nV1MuOzLr6NUbJIiKRAJrmci+ovIQEMwMhvvrHQZMX1/ rWYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718826014; x=1719430814; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CK8hz4LxEC8FEUSar0dSbTbJ1JKQi4AD6vWGMU0oeJs=; b=lp6ngO3MO9ahM49VWOOEmtHgrZTr1XCMujVk9ONGw7vFtGIwAZLbFXWIxbAj9hPxJ0 8QEa3XbO7osuuRf0NYSJ8PLV75gVYJxQAioxL9cPbgb/FEcVa7QTpcwWZw81gBThUsjy ptyqOUrDx5ZXUbe4rsm3EfMoWQgdNfonhyR9AO2EuJOIbGmZK7Nu+IYC1VthmUoAvp7m a+bEUF5yQP+XOpwLbqZDEppgFFML+169N6cMJtHPX2vCUk+VjzY6ZHnHLGUqHRNapD8/ EIJC+JfQ9Gi79QsHMoAMMvUhmG5Ouj/wA3Z+nGsdzEljdH/RQgrj38y2oViVnXNgkL44 4c0w== X-Gm-Message-State: AOJu0Yw04cEgdCa3RTq8jNDd7Wm4u9Tu5G0sI6rU+hgKxF6FNYkr2p00 i/Cr+Mmk9VXmQVwC/Rt6iixWHfV8LT4159/cLzuIHKFhbfj+DjRT X-Google-Smtp-Source: AGHT+IHpJOB0KRyjEBGgfo1MFRwxoCC250F0vj9ubalhHu8lHTyiGDdQJod0tImIfOPxJQhgEDQg3A== X-Received: by 2002:a17:902:c412:b0:1f3:903:5c9a with SMTP id d9443c01a7336-1f9aa46dbebmr35689975ad.58.1718826013632; Wed, 19 Jun 2024 12:40:13 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-1f9c3d82d05sm3712355ad.244.2024.06.19.12.40.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jun 2024 12:40:13 -0700 (PDT) Message-ID: Date: Wed, 19 Jun 2024 12:40:12 -0700 MIME-Version: 1.0 Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Content-Language: en-US To: Eli Zaretskii References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> From: Jim Porter In-Reply-To: <86v824ohym.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. 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 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). 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. 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). From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 20 00:53:27 2024 Received: (at 71655) by debbugs.gnu.org; 20 Jun 2024 04:53:28 +0000 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 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 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==; Date: Thu, 20 Jun 2024 07:53:12 +0300 Message-Id: <86r0csnrk7.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: (message from Jim Porter on Wed, 19 Jun 2024 12:40:12 -0700) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 20 01:35:16 2024 Received: (at 71655) by debbugs.gnu.org; 20 Jun 2024 05:35:16 +0000 Received: from localhost ([127.0.0.1]:44261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKAS4-0001qE-9x for submit@debbugs.gnu.org; Thu, 20 Jun 2024 01:35:16 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:44497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKAS1-0001pt-6z for 71655@debbugs.gnu.org; Thu, 20 Jun 2024 01:35:14 -0400 Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-7062bf6d9a1so409110b3a.1 for <71655@debbugs.gnu.org>; Wed, 19 Jun 2024 22:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718861644; x=1719466444; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=khEyYjkCEYdoVEgqD0bdPAhgrIPEx8Di5KdziJjB9OE=; b=R+JRyb0atSk4t2s9zoVLMRTdeWJ+7lbR5CgdSPQAunDIrY3aT/UOgJHej/vYrSZ5Rn BZuD3iq9dn8QpujGepDnseUD1iKsTzZXVnVNi/V0lVKIkArfXwovSFwJD9YwxTz9bfQa +R9f8T3/HD3Ca6RqIC/ugZKsHMExMbPS0xtnRfDXTCRiu2/zmpP5hHcHbUE1vWCGKTZf cBQj0S77H3jWesp64SryTI7ocU8CYM7ZNHleWk83eetFknSu1Ducj1Or8ukHPbF+nZSN cW8Rfvq6Szu0Y+8MdIlwZCnFMIxFo8SIQ6nOp7G5Gj538PS/C/I9+mhrFN3/HFL6Wt2Q C4Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718861644; x=1719466444; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=khEyYjkCEYdoVEgqD0bdPAhgrIPEx8Di5KdziJjB9OE=; b=m1hFDiA30UpFCesn7Rh62Icvi79TrnC+EC1B6MTfv/f5TTLHJ91cBdAZ3yk002zmze A03Scbv2+o/OHNAvpGVpZFRCqQ8R6ZPQnDD9TocFaSPxLpyJ3fZ85cwkUMZ+AvkZtIyx LZo7dt054wHSsdbeCJlpDnQI/lUuBBZLUkxK+D/MpTEB+e/8FchpVaMn41Lj7xqey8Iz bBmWLKJL5b0YNxG8yoEvBbmgc/V32Do3KAG9p4kRoe4ciRGj9SDN73ZZtC99rSmJSR8q Y4KS8o8JDfZxbZ0HXD71k7fY40+bEp1Bef+5Oy6c3BXk/6dYIAsAHF05KEI1ktZqidIi tG9A== X-Gm-Message-State: AOJu0YyBjFtTutVaHpGMt+Cp13ueN+dMeHsUWMifJ9Q2eoF2eFlsLtO6 eyqn/ecn+DZsljYUloZgIkfnDoA0x9Oa/Z30NfvT3m/2R0k1c8TX X-Google-Smtp-Source: AGHT+IFwQ2wpvdCE4Lkh8gc1rGc+UXKzblF+oKIr1cqlu94TLHUikoNY4bmDv9lvwqiB5p5qFWYWew== X-Received: by 2002:a05:6a00:278e:b0:706:2954:36f5 with SMTP id d2e1a72fcca58-70629c67897mr4693778b3a.18.1718861643499; Wed, 19 Jun 2024 22:34:03 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d2e1a72fcca58-705ccb6b110sm11601025b3a.153.2024.06.19.22.34.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jun 2024 22:34:03 -0700 (PDT) Message-ID: <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> Date: Wed, 19 Jun 2024 22:34:02 -0700 MIME-Version: 1.0 Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Content-Language: en-US To: Eli Zaretskii References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> From: Jim Porter In-Reply-To: <86r0csnrk7.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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? > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 20 03:46:03 2024 Received: (at 71655) by debbugs.gnu.org; 20 Jun 2024 07:46:03 +0000 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 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 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==; Date: Thu, 20 Jun 2024 10:45:46 +0300 Message-Id: <86cyocnjkl.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> (message from Jim Porter on Wed, 19 Jun 2024 22:34:02 -0700) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 22 15:56:44 2024 Received: (at 71655) by debbugs.gnu.org; 22 Jun 2024 19:56:45 +0000 Received: from localhost ([127.0.0.1]:58384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sL6qq-00021Q-6E for submit@debbugs.gnu.org; Sat, 22 Jun 2024 15:56:44 -0400 Received: from mail-pf1-f179.google.com ([209.85.210.179]:59880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sL6qn-000219-Pn for 71655@debbugs.gnu.org; Sat, 22 Jun 2024 15:56:42 -0400 Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-7065e2fe7d9so1022177b3a.3 for <71655@debbugs.gnu.org>; Sat, 22 Jun 2024 12:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719086136; x=1719690936; darn=debbugs.gnu.org; h=in-reply-to:from:references:cc:to:content-language:subject :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=uIA97+1FVQrmt326V0frWlTEOTbu6wkihHkCiXYGwSg=; b=cWu7zOjg1ZjZIYRgdkb99/lWH7H41q/EYC9eluRvG0gqEEdNQLbxsFgq4FqwHoROV2 4DVukah0o60YY0KDftlWvebUa/4iDFhxJ+9wvrhzjX/9wDYf5NLrs+4VhPlvAUYLkrGs foxunird5nU24jPUzk75zSWpB+XpR6caJVb6C3OnDtW2y15N3ywjYIKn0SuJ7nwhPiLx 4YcNgSFhCV4qlAAe8F8tvmz636GBZP0QSVXutAcNfEeF1+YRR1hVeSVkaHrzq5aR44yq 4E7WsoRy+BLRSzaYEqeHAb6vfEBRBAH9qld5BdNqArL84n86mzNKlS8cskB8IvlSJMUE OUPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719086136; x=1719690936; h=in-reply-to:from:references:cc:to:content-language:subject :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=uIA97+1FVQrmt326V0frWlTEOTbu6wkihHkCiXYGwSg=; b=bLoveKe+m/TjeiLdZ1EbsBrlFD4IrNN5BoryCK5+yuGB998D9LY17rkW3g+gQ9Hxaf 3Vexta1r45j14ppPkJWOdRDtq2icftH5G28tC/grLRNfJcteFA11siw6NmeNidaV6Fdc /XOcEEjrrXO9/f3mR7v1RcuzNlMxYbkP1uKIeAdlgntCIwE2n2IXrmrbQltbRtDkXXQs Q3UKWtESS2DtkIxaDyq8by0AjbK/kH+IjhJQTODP5FRyLDzCaBtNlXzQg50rNQ3CqSFy 80Tgt/VNCKQacIAarR5o1QbksL7+ZgQ64EzJn+111iwHpBSUCvRtMNc6Rk9K892HLjMR mmVg== X-Gm-Message-State: AOJu0YwnfFFJiUOJOcL2T42nLu9skPFxAbYSZqGjuG5aWniC02a3oHfL LE6UG6SmPRzirIlzxLqk9ugU4t+Fjeo2cZzLPXAIF+oEoZR77n2c X-Google-Smtp-Source: AGHT+IG4llhJKAOL4Zjf63EJBahojwBnFateHvvYHdpIzPgipcfg/TERHjpaFqQx96QFLcyY+JoP4g== X-Received: by 2002:a05:6a20:f3a7:b0:1bc:c4d1:7810 with SMTP id adf61e73a8af0-1bcf7eb5317mr645229637.29.1719086135372; Sat, 22 Jun 2024 12:55:35 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d2e1a72fcca58-7065130573esm3414530b3a.205.2024.06.22.12.55.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jun 2024 12:55:33 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------R0Y4mMf08MKFpJ1aKYukslq0" Message-ID: <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> Date: Sat, 22 Jun 2024 12:55:32 -0700 MIME-Version: 1.0 Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Content-Language: en-US To: Eli Zaretskii References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> From: Jim Porter In-Reply-To: <86cyocnjkl.fsf@gnu.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------R0Y4mMf08MKFpJ1aKYukslq0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/20/2024 12:45 AM, Eli Zaretskii wrote: >> Date: Wed, 19 Jun 2024 22:34:02 -0700 >> Cc: 71655@debbugs.gnu.org, james@literate-devops.io >> From: Jim Porter >> >> 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. Right. This was just (what I thought was) an interesting observation about how other POSIX-based tools treat these reparse points. > I agree that all those other conditions (including the .exe test) seem > to be reasonable, in addition to zero-size. Do you have a preference between either of these patches? They either check for zero-size or ignore file errors when trying to insert. I don't have a strong preference myself, but the latter seems ever-so-slightly safer to me. This bug happened because we can't read the file when trying to insert it, so ignoring file errors would cover any other situations we haven't predicted. On the other hand, maybe there's a case where we *want* the 'insert-file-contents-literally' error to signal so that we don't try to execute the file normally (I can't think of any such cases, though). --------------R0Y4mMf08MKFpJ1aKYukslq0 Content-Type: text/plain; charset=UTF-8; name="0001-Use-file-attribute-size.patch" Content-Disposition: attachment; filename="0001-Use-file-attribute-size.patch" Content-Transfer-Encoding: base64 RnJvbSA0NTIxZjgyZGNlZjAyNTM1NjQ1NzQwMTJjNTcxNTY0MTExZTA2YzRhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IFNhdCwgMjIgSnVuIDIwMjQgMTI6NDU6MTkgLTA3MDAKU3ViamVjdDogW1BB VENIXSBGaXggZXhlY3V0aW9uIG9mIE1TLVdpbmRvd3MgYXBwIGV4ZWN1dGlvbiBhbGlhc2Vz IGluIEVzaGVsbAoKKiBsaXNwL2VzaGVsbC9lc2gtZXh0LmVsIChlc2hlbGwtc2NyaXB0LWlu dGVycHJldGVyKTogQ2hlY2sgZm9yIDAtc2l6ZQpmaWxlcy4KLS0tCiBsaXNwL2VzaGVsbC9l c2gtZXh0LmVsIHwgMTIgKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMTEgaW5zZXJ0 aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2xpc3AvZXNoZWxsL2VzaC1l eHQuZWwgYi9saXNwL2VzaGVsbC9lc2gtZXh0LmVsCmluZGV4IDNjNGRlYjMyNjAxLi5jZjkz ZDI5MDRkYSAxMDA2NDQKLS0tIGEvbGlzcC9lc2hlbGwvZXNoLWV4dC5lbAorKysgYi9saXNw L2VzaGVsbC9lc2gtZXh0LmVsCkBAIC0zMDEsNyArMzAxLDE3IEBAIGVzaGVsbC1zY3JpcHQt aW50ZXJwcmV0ZXIKICAgKElOVEVSUFJFVEVSIFtBUkdTXSBGSUxFKSIKICAgKGxldCAoKG1h eGxlbiBlc2hlbGwtY29tbWFuZC1pbnRlcnByZXRlci1tYXgtbGVuZ3RoKSkKICAgICAoaWYg KGFuZCAoZmlsZS1yZWFkYWJsZS1wIGZpbGUpCi0JICAgICAoZmlsZS1yZWd1bGFyLXAgZmls ZSkpCisJICAgICAoZmlsZS1yZWd1bGFyLXAgZmlsZSkKKyAgICAgICAgICAgICA7OyBJZiB0 aGUgZmlsZSBpcyB6ZXJvIGJ5dGVzLCBpdCBjYW4ndCBwb3NzaWJseSBoYXZlIGEKKyAgICAg ICAgICAgICA7OyBzaGViYW5nLiAgVGhpcyBjaGVjayBtYXkgc2VlbSByZWR1bmRhbnQsIGJ1 dCB3ZSBjYW4KKyAgICAgICAgICAgICA7OyBlbmNvdW50ZXIgZmlsZXMgdGhhdCBFbWFjcyBj b25zaWRlcnMgYm90aCByZWFkYWJsZSBhbmQKKyAgICAgICAgICAgICA7OyByZWd1bGFyLCBi dXQgd2hpY2ggYXJlbid0ICphY3R1YWxseSogcmVhZGFibGUuICBUaGlzIGNhbgorICAgICAg ICAgICAgIDs7IGhhcHBlbiwgZm9yIGV4YW1wbGUsIHdpdGggY2VydGFpbiBraW5kcyBvZiBy ZXBhcnNlCisgICAgICAgICAgICAgOzsgcG9pbnRzIGxpa2UgQVBQRVhFQ0xJTksgb24gTlRG UyBmaWxlc3lzdGVtcyAoTVMtV2luZG93cworICAgICAgICAgICAgIDs7IHVzZXMgdGhlc2Ug Zm9yICJhcHAgZXhlY3V0aW9uIGFsaWFzZXMiKS4gIEluIHRoZXNlCisgICAgICAgICAgICAg OzsgY2FzZXMsIHRoZSBmaWxlIHNpemUgaXMgMCwgc28gdGhpcyBjaGVjayBwcm90ZWN0cyB1 cworICAgICAgICAgICAgIDs7IGZyb20gZXJyb3JzLgorICAgICAgICAgICAgICg+IChmaWxl LWF0dHJpYnV0ZS1zaXplIChmaWxlLWF0dHJpYnV0ZXMgZmlsZSkpIDApKQogCSh3aXRoLXRl bXAtYnVmZmVyCiAJICAoaW5zZXJ0LWZpbGUtY29udGVudHMtbGl0ZXJhbGx5IGZpbGUgbmls IDAgbWF4bGVuKQogCSAgKGlmIChsb29raW5nLWF0ICIjIVsgXHRdKlxcKFteIFxyXHRcbl0r XFwpXFwoWyBcdF0rXFwoLitcXClcXCk/IikKLS0gCjIuMjUuMQoK --------------R0Y4mMf08MKFpJ1aKYukslq0 Content-Type: text/plain; charset=UTF-8; name="0001-Use-ignore-error.patch" Content-Disposition: attachment; filename="0001-Use-ignore-error.patch" Content-Transfer-Encoding: base64 RnJvbSA1NWNmMzA4OGQwMDc1ZjdkNDUzZWVjYjFlMDM2ODNkZTQ0NDRlYjRmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IFNhdCwgMjIgSnVuIDIwMjQgMTI6NDE6MjUgLTA3MDAKU3ViamVjdDogW1BB VENIXSBGaXggZXhlY3V0aW9uIG9mIE1TLVdpbmRvd3MgYXBwIGV4ZWN1dGlvbiBhbGlhc2Vz IGluIEVzaGVsbAoKKiBsaXNwL2VzaGVsbC9lc2gtZXh0LmVsIChlc2hlbGwtc2NyaXB0LWlu dGVycHJldGVyKTogUmV0dXJuIG5pbCBpZiB3ZQpjYW4ndCBhY3R1YWxseSByZWFkIHRoZSBm aWxlLgotLS0KIGxpc3AvZXNoZWxsL2VzaC1leHQuZWwgfCAyOSArKysrKysrKysrKysrKysr Ky0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE3IGluc2VydGlvbnMoKyksIDEyIGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvZXNoZWxsL2VzaC1leHQuZWwgYi9saXNw L2VzaGVsbC9lc2gtZXh0LmVsCmluZGV4IDNjNGRlYjMyNjAxLi42ZmIwNTc5ZWQxNCAxMDA2 NDQKLS0tIGEvbGlzcC9lc2hlbGwvZXNoLWV4dC5lbAorKysgYi9saXNwL2VzaGVsbC9lc2gt ZXh0LmVsCkBAIC0yOTksMTggKzI5OSwyMyBAQCBlc2hlbGwtc2NyaXB0LWludGVycHJldGVy CiBSZXR1cm4gbmlsLCBvciBhIGxpc3Qgb2YgdGhlIGZvcm06CiAKICAgKElOVEVSUFJFVEVS IFtBUkdTXSBGSUxFKSIKLSAgKGxldCAoKG1heGxlbiBlc2hlbGwtY29tbWFuZC1pbnRlcnBy ZXRlci1tYXgtbGVuZ3RoKSkKLSAgICAoaWYgKGFuZCAoZmlsZS1yZWFkYWJsZS1wIGZpbGUp Ci0JICAgICAoZmlsZS1yZWd1bGFyLXAgZmlsZSkpCi0JKHdpdGgtdGVtcC1idWZmZXIKLQkg IChpbnNlcnQtZmlsZS1jb250ZW50cy1saXRlcmFsbHkgZmlsZSBuaWwgMCBtYXhsZW4pCi0J ICAoaWYgKGxvb2tpbmctYXQgIiMhWyBcdF0qXFwoW14gXHJcdFxuXStcXClcXChbIFx0XStc XCguK1xcKVxcKT8iKQotCSAgICAgIChpZiAobWF0Y2gtc3RyaW5nIDMpCi0JCSAgKGxpc3Qg KG1hdGNoLXN0cmluZyAxKQotCQkJKG1hdGNoLXN0cmluZyAzKQotCQkJZmlsZSkKLQkJKGxp c3QgKG1hdGNoLXN0cmluZyAxKQotCQkgICAgICBmaWxlKSkpKSkpKQorICAod2hlbiAoYW5k IChmaWxlLXJlYWRhYmxlLXAgZmlsZSkKKyAgICAgICAgICAgICAoZmlsZS1yZWd1bGFyLXAg ZmlsZSkpCisgICAgKGxldCAoKG1heGxlbiBlc2hlbGwtY29tbWFuZC1pbnRlcnByZXRlci1t YXgtbGVuZ3RoKSkKKyAgICAgIDs7IElmIHdlIGVuY291bnRlciBhIGZpbGUgZXJyb3IsIGFz c3VtZSB0aGF0IEZJTEUgZG9lc24ndCBoYXZlIGEKKyAgICAgIDs7IHNoZWJhbmcuICBUaGlz IGNhbiBoYXBwZW4sIGZvciBleGFtcGxlLCB3aXRoIGNlcnRhaW4ga2luZHMgb2YKKyAgICAg IDs7IHJlcGFyc2UgcG9pbnRzIGxpa2UgQVBQRVhFQ0xJTksgb24gTlRGUyBmaWxlc3lzdGVt cyAoTVMtV2luZG93cworICAgICAgOzsgdXNlcyB0aGVzZSBmb3IgImFwcCBleGVjdXRpb24g YWxpYXNlcyIpLgorICAgICAgKGlnbm9yZS1lcnJvciAnZmlsZS1lcnJvcgorICAgICAgICAo d2l0aC10ZW1wLWJ1ZmZlcgorICAgICAgICAgIChpbnNlcnQtZmlsZS1jb250ZW50cy1saXRl cmFsbHkgZmlsZSBuaWwgMCBtYXhsZW4pCisgICAgICAgICAgKGlmIChsb29raW5nLWF0ICIj IVsgXHRdKlxcKFteIFxyXHRcbl0rXFwpXFwoWyBcdF0rXFwoLitcXClcXCk/IikKKyAgICAg ICAgICAgICAgKGlmIChtYXRjaC1zdHJpbmcgMykKKyAgICAgICAgICAgICAgICAgIChsaXN0 IChtYXRjaC1zdHJpbmcgMSkKKyAgICAgICAgICAgICAgICAgICAgICAgIChtYXRjaC1zdHJp bmcgMykKKyAgICAgICAgICAgICAgICAgICAgICAgIGZpbGUpCisgICAgICAgICAgICAgICAg KGxpc3QgKG1hdGNoLXN0cmluZyAxKQorICAgICAgICAgICAgICAgICAgICAgIGZpbGUpKSkp KSkpKQogCiAoZGVmdW4gZXNoZWxsLWZpbmQtaW50ZXJwcmV0ZXIgKGZpbGUgYXJncyAmb3B0 aW9uYWwgbm8tZXhhbWluZS1wKQogICAiRmluZCB0aGUgY29tbWFuZCBpbnRlcnByZXRlciB3 aXRoIHdoaWNoIHRvIGV4ZWN1dGUgRklMRS4KLS0gCjIuMjUuMQoK --------------R0Y4mMf08MKFpJ1aKYukslq0-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 23 00:38:51 2024 Received: (at 71655) by debbugs.gnu.org; 23 Jun 2024 04:38:51 +0000 Received: from localhost ([127.0.0.1]:43850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLF07-0004lq-1H for submit@debbugs.gnu.org; Sun, 23 Jun 2024 00:38:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLF05-0004la-QC for 71655@debbugs.gnu.org; Sun, 23 Jun 2024 00:38:50 -0400 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 1sLExt-0003w2-RO; Sun, 23 Jun 2024 00:36:33 -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=H0yA4HE7CYxvQ8npuBEhuw+8jH2r4J+EPNnPrY7tuvg=; b=sXgs8Yg9AF6b Y/zcPS6NPCahQF2StQYFS1zURiZQY0MEa5j6gseOU+myOZzuuie1mh3IffMTxkSsCdjpCHNDJ5YDt CVIZpT2P4au3av2P+t4gP6WPkVD8Tcsm1BlbaEYhd3ZcDONcrMA/kL7LldupZqwH3QiNiUtKvgrNZ +mhWGUnboEuCuMgAzBl/+JEc1GwrN64p9egGUBVHcDJCZwz6lrmbAlkpZk5IDRHljq067CpHw1Aa3 hcn7PqYyFsKXyTc+G/4NZsl8ULpLaifDl2di+lZhqQXRhY7PezhZWChh6sxY8I9xM9JMkxEt2+GKr RJrYhkKDl4keUMtlg8IXzw==; Date: Sun, 23 Jun 2024 07:36:32 +0300 Message-Id: <86pls8ff73.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> (message from Jim Porter on Sat, 22 Jun 2024 12:55:32 -0700) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 22 Jun 2024 12:55:32 -0700 > Cc: 71655@debbugs.gnu.org, james@literate-devops.io > From: Jim Porter > > > I agree that all those other conditions (including the .exe test) seem > > to be reasonable, in addition to zero-size. > > Do you have a preference between either of these patches? They either > check for zero-size or ignore file errors when trying to insert. > > I don't have a strong preference myself, but the latter seems > ever-so-slightly safer to me. This bug happened because we can't read > the file when trying to insert it, so ignoring file errors would cover > any other situations we haven't predicted. On the other hand, maybe > there's a case where we *want* the 'insert-file-contents-literally' > error to signal so that we don't try to execute the file normally (I > can't think of any such cases, though). Why not do both? If the file has zero size, reading it is pointless, and if reading it signals an error, we cannot examine it for the interpreter signature. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 23 21:41:48 2024 Received: (at 71655) by debbugs.gnu.org; 24 Jun 2024 01:41:48 +0000 Received: from localhost ([127.0.0.1]:60689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLYiK-0005Jf-Cq for submit@debbugs.gnu.org; Sun, 23 Jun 2024 21:41:48 -0400 Received: from mail-pl1-f182.google.com ([209.85.214.182]:61885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLYiG-0005JK-SH for 71655@debbugs.gnu.org; Sun, 23 Jun 2024 21:41:46 -0400 Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1fa0f143b85so8884005ad.3 for <71655@debbugs.gnu.org>; Sun, 23 Jun 2024 18:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719193238; x=1719798038; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=gKMvvuTt3fNLnmgoMrmkpZRJy4huGesO5rtxfejhNQA=; b=gdsEbJbVWxtTV4lOa5p0le2oTV1G+vsQu/x6hKCkkqUfSzi+Hvetn0JlN6mGmhFK4O TF+v1+Pu69l+NFeBZLY0ibN8U51n6bWgeVmGntGwF+ZMX4isulOGL5K69LdN/a7Gah2X pXPAv1IFvm8YEOWgUnOJIBXUGLUldUY5/3xNXUWjfyLlKVmJInmhcn1/GGatSkYxRFIe 18il1KTJxNtbtZhit172sBNwQUuiv6lySRTnwWmHCvcwSkxI6AnWaNQaCyTXR+KM/Vgo esco8QsEf579YOdjNWlOPDAtc/QKdpW2qQqeGAfOqoDwCt0dMDciCRqObWl0WUQIM8cU bKPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719193238; x=1719798038; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gKMvvuTt3fNLnmgoMrmkpZRJy4huGesO5rtxfejhNQA=; b=OtKaSq18WYOoKDDexxkVs40J4X+JTGLcVp6LRMzbi/Kq9XtHoyvq7NCax6TofkU2PA W+anCTwwvRfqpxX1E32hySkPKjylSlL7iH+uG4jcTzA+gwpnhltnH9rp4wWXEjeMW9vV g4tOVOJ+8D8XikERamhbdzfneSVZkXXiH2tg1z7kSeMxfxGAMxN0QOuRROpJLtyrdetA YYoMyxXNlrt2VH7ozEBvRzjsh6Dnoj8jtZAB+lLIZ8hD0ihwl0t3wwAB4S/n7rEDgIP6 JiwZXV+SgOANIpryd54x6T/7Wd9WmsO2imeUeHvtUV/7Gaiws/6nbC1InA5FQt3WEs2H Vs9Q== X-Gm-Message-State: AOJu0YwF7pZcBMQrGd45pkglLItMDBOdsqTRUqiWttTqbP7u+A1L1vq9 9GosuALacp0zH7+ChfRzsQ50tjqNUv+mmEHHd3Ob7X7OAqpt54sM X-Google-Smtp-Source: AGHT+IGDORuSM/kMowVWf6iPtPtgfuPbc7INzSYDxUTyYX/mJPCrlIf5YohaVt/9ubmVkNCNUvMbmw== X-Received: by 2002:a17:903:186:b0:1fa:a46:aa56 with SMTP id d9443c01a7336-1fa23f1d2dfmr26844345ad.51.1719193238093; Sun, 23 Jun 2024 18:40:38 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-1f9eb323614sm51044195ad.70.2024.06.23.18.40.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Jun 2024 18:40:37 -0700 (PDT) Message-ID: Date: Sun, 23 Jun 2024 18:40:37 -0700 MIME-Version: 1.0 Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Content-Language: en-US To: Eli Zaretskii References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> <86pls8ff73.fsf@gnu.org> From: Jim Porter In-Reply-To: <86pls8ff73.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71655 Cc: 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 6/22/2024 9:36 PM, Eli Zaretskii wrote: >> Date: Sat, 22 Jun 2024 12:55:32 -0700 >> Cc: 71655@debbugs.gnu.org, james@literate-devops.io >> From: Jim Porter >> >> I don't have a strong preference myself, but the latter seems >> ever-so-slightly safer to me. This bug happened because we can't read >> the file when trying to insert it, so ignoring file errors would cover >> any other situations we haven't predicted. On the other hand, maybe >> there's a case where we *want* the 'insert-file-contents-literally' >> error to signal so that we don't try to execute the file normally (I >> can't think of any such cases, though). > > Why not do both? If the file has zero size, reading it is pointless, > and if reading it signals an error, we cannot examine it for the > interpreter signature. That could work, though thinking about this some more, I think there's a benefit to being careful about how we add checks here. For Tramp files, we should probably try to keep the number of calls that need to touch the remote filesystem to a minimum. 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.) From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 24 01:56:31 2024 Received: (at 71655) by debbugs.gnu.org; 24 Jun 2024 05:56:31 +0000 Received: from localhost ([127.0.0.1]:41075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLcgo-0006lk-TF for submit@debbugs.gnu.org; Mon, 24 Jun 2024 01:56:31 -0400 Received: from mout.gmx.net ([212.227.15.18]:37139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sLcgl-0006lR-UT for 71655@debbugs.gnu.org; Mon, 24 Jun 2024 01:56:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1719208577; x=1719813377; i=michael.albinus@gmx.de; bh=MsPiM0c75KRGEvDdV/2llRn3prHoH/YH5Wegpq4cEUg=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=b+WmZZSmMERteOMPV+PJXpAd2LkO8Lud35UrmUFhsG0fc19GI9AmmfS2u0l/sxct WqgkdXHZWvMzfyJfJVMvpwWyiDXJJHHd+LkdCCKkBSDGYDIsRolPQW2cW7F7Ip1c/ oD5BFG5Q7zfKU3Hy0Yz21QgzQ2Rxi3GzkA7lqcXFqPxsW6W2ykajD5ChY1J2KnNHn 0fxbb0ae6rt3SHGDtdkhnZBIQgQHL95K4fM2TvgwFzaSs2t+WJjAX7Md1yr8fmijz ng0tTZwVYu8Cl7zbZcm46p80KGpDEWTvSYDx4I8cp8+ffwwI+00FoUHanMUQzB6t+ c9zjx6tB9Y3PK9iDkw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.38.155]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mi2Nv-1sqIk42xRh-00fbPY; Mon, 24 Jun 2024 07:56:17 +0200 From: Michael Albinus To: Jim Porter Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows In-Reply-To: (Jim Porter's message of "Sun, 23 Jun 2024 18:40:37 -0700") References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> <86pls8ff73.fsf@gnu.org> Date: Mon, 24 Jun 2024 07:56:16 +0200 Message-ID: <875xtyyjcv.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:feM0G5w/iMvYrYLVzwrT9nWcSa2BxuKm06W10mZwbW1yxi74rOU HoypByskbTOaatxLKgQpIZ6g4lSL3CFquuHzaZLsEUCGElfqjSfbtoeLkXLU+gUtsoi9MLl 50kReIh+EyOMQsWce3lYWVRGILumCTSh9IET2s8ECebm3h65cpeOT20Fij32hL0FySgpiIY H+eXkbh8fLkHd11GxW3vQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:9jDgGiZjCw8=;79EmVovjmGXWlxrWmo4eIYL+KdJ KxUIeaDETEe+xM1/MmaUqRs4l/WweMEVYwPkeqTs29rtIy2wWul6OVw3EQXFlPlYVqE2endQY PcUY/ZHcqT8A2xePpc3uEQelS5cJcuH5FRZ5f6RDOeDWhVGcFeovl26h1NYRtSngbl8iN98ep UeWHoMHSJBAC6ryKDYd/NnqP9UHj0jan/AY6rm9tD8QUX1LWZ9pj8cCIz3fOOUqniRcix/v2c NkNoBsqDJXtCpZH2QkOORCian8zje7jUQ9UbEFaNAhs7dZv2ILsEIVoJie6jB/g2y3sJjRi8Y Ij2p5hmUkxTJE1bhbpkyuI85mGP6QByAm7VD0T8qqROhEm2VuiJWhZdK3v+4FhfKNHxN6uJuL VkG540u8AdUFkfmvZthvLLPseJ8oruuu1QvK/Vvzm8kOKJH+ABqAuQaiadDAc7TzpAGJcRYCG LMMWD64pAet3KmlHU+BUdGXJOT27HGEwRr91WmHFkkxXAN+F25YM4vYzlCR9r0DBTJ6LNLEF4 TmUdMweil5QayDLj6i/1sQcM65irdcbpHEdMKldrXOYI5Ysc0he+29RqySGQvZpwyAVzw9tKh JlkErnEDZ623JV5++qeAkfmRPNnah0eKkBBO16T7SMGtz3rtLYHKJoS6E+xN7Gu36Ixag1pBQ AqYXtZC8bfMVgKcvvOSMUzpshSWVubJgt8VqyUsvVjI3mPpP9MWBaxTFe6pJDDtzDQ0Xvd7p9 0Ihu3VRmydn7vypwLi9mYzpwE7JfLlW/3XIYoC3jzg2VEn3/Pn1lSTJslIcxQSa7oLRdx50yC T6LQa8DabV+rOWOW7GLjt7leyqMXmZ1hPOe3sYEamy8L0= X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Jim Porter writes: Hi Jim, > That could work, though thinking about this some more, I think there's > a benefit to being careful about how we add checks here. For Tramp > files, we should probably try to keep the number of call [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [185.89.38.155 listed in zen.spamhaus.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.227.15.18 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 71655 Cc: Eli Zaretskii , 71655@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Jim Porter writes: Hi Jim, > That could work, though thinking about this some more, I think there's > a benefit to being careful about how we add checks here. For Tramp > files, we should probably try to keep the number of call [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [185.89.38.155 listed in zen.spamhaus.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.227.15.18 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Jim Porter writes: Hi Jim, > That could work, though thinking about this some more, I think there's > a benefit to being careful about how we add checks here. For Tramp > files, we should probably try to keep the number of calls that need to > touch the remote filesystem to a minimum. > > 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. In case Eshell needs to clear the cache for a given directory, there is `dired-uncache'. Contrary to its name, it is not restricted to dired, but of general purpose. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 07 23:27:31 2024 Received: (at 71655-done) by debbugs.gnu.org; 8 Jul 2024 03:27:31 +0000 Received: from localhost ([127.0.0.1]:49392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQf2J-0007ba-0R for submit@debbugs.gnu.org; Sun, 07 Jul 2024 23:27:31 -0400 Received: from mail-pl1-f182.google.com ([209.85.214.182]:43016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQf2H-0007bM-6x for 71655-done@debbugs.gnu.org; Sun, 07 Jul 2024 23:27:29 -0400 Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1faad2f1967so29794835ad.0 for <71655-done@debbugs.gnu.org>; Sun, 07 Jul 2024 20:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720409179; x=1721013979; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=audRt7fRtaHJAypC2zr5a+4S4wIdbMdzCDcLlozMhh4=; b=YzT7BZE7O+YzUbe2PhtX3FnnobBqB6js0J+OxCMLjboPARC4/2hWWBlfiDqE4pdhw3 ofMm9PrhsqTbj2MvrdjOTxXUVz7B0ykTzq9bRALx0xgFiitLHjFpQTPv0hqq3lKoQukP xQ2WWVPAuXsqYW6vmIflIA/y/MHfCHO4/oEKQqiEOG+WPS/Yb3SFyGq1CdBKOHJwjJNo JVEaCEsWc8DhEAbV4MNCsTtdPOqUV50KeIn3cbLTVutqaJWHD4vJ6FIvtrgrzAyLhqdo JgUAFww9ixlquglUXvppvpnENxXGZFe+zX8SfQzhLdWn3DMbLzk4sA3aXVrmBKna4Hwo pnYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720409179; x=1721013979; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=audRt7fRtaHJAypC2zr5a+4S4wIdbMdzCDcLlozMhh4=; b=roxw8CKcah90AXWfXahezx9ioq4ekYm6sZUOiMNP2DVijpGECaCmPEJsbu7ui0JuRy 8TRqZpiEuwsW+wBuyDU8ihNApW1B7AnkD52baFH8ytfSFgAR9XAGN8iNwjFkuVDIDVNE +Awpq4Cuam8NPf6S+BHV8k7NvVZ3Q4gD7fmINLgpUe3mQeHxnWRoIT5z+H9m4ix9uwn4 ewk21CgPZlL1a2uXBGqIQJ8X4lee2Q7tHUSlVnM669Z30AHkpKk/Y2twUno5tt8gcPAp LpevIrg/vULNCnRsbEkDhEOnn74vxE7jJJQysh1/Nbm43DnSIFz4b6pYPvUPwW5txY4+ cWHQ== X-Forwarded-Encrypted: i=1; AJvYcCWj5KL9hNzTq0nl2Qt4/mH/7qb1h3Sc/gXBpe+WHQAP3pwPGHCoqRoTXiEgfujoKQX+HXcEt7yufdgOw36sM3cGckztilpT7TYzdw== X-Gm-Message-State: AOJu0YyyzKnIwQam/WjFN5Zf3CTBCZQc/UbP+2upzYN+Ujb3R5LlmqVC 2gd1fCcNUNit5nnvVNEjuk80V0EeVmeO54/bXgtFtz0zurC3dkuS X-Google-Smtp-Source: AGHT+IG+2Gcn8gUnXGjIKywglOyw9EqNs/vCXMEJJAFf7vVhUrPwC7pbEdy+yuVlxkaZ/JNZNTg/4w== X-Received: by 2002:a17:903:41ce:b0:1fa:2b11:657d with SMTP id d9443c01a7336-1fb37037269mr158055285ad.10.1720409178554; Sun, 07 Jul 2024 20:26:18 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-1fb2b1e60a4sm72927795ad.235.2024.07.07.20.26.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jul 2024 20:26:18 -0700 (PDT) Message-ID: Date: Sun, 7 Jul 2024 20:26:17 -0700 MIME-Version: 1.0 Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Content-Language: en-US To: Michael Albinus References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> <86pls8ff73.fsf@gnu.org> <875xtyyjcv.fsf@gmx.de> From: Jim Porter In-Reply-To: <875xtyyjcv.fsf@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71655-done Cc: Eli Zaretskii , 71655-done@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 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.) From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 08 07:09:56 2024 Received: (at 71655-done) by debbugs.gnu.org; 8 Jul 2024 11:09:56 +0000 Received: from localhost ([127.0.0.1]:49809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQmFn-0005pB-Kh for submit@debbugs.gnu.org; Mon, 08 Jul 2024 07:09:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQmFl-0005ou-JZ for 71655-done@debbugs.gnu.org; Mon, 08 Jul 2024 07:09:54 -0400 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 1sQmFa-0001em-U2; Mon, 08 Jul 2024 07:09:42 -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=iG3B3AEWW2rc1ydVA+q2hYvFSPGt6Z1v/hQ/24BvjBA=; b=OIAN90tncDE7 1ukoYbKJgdBz8DGOxjcMInwwQmBBqxBBKyqlf/X4tc5IdnRmKZd0LAMcqbtYqjY0bZINBhjowJGrd n8vjiR1O+oNUxAdnkffcFvMfdLoUEMpFTwwURrMhPtkcy48a6hmA0rKWhzVk+s8f4mUUgQ04bGOIm igEANP9IB6mDbMoVbgSN5XiZF4RhpHwzAHnr+7GyPNX7boLGSvej2WmdUKgDtdlIQ+m/GBaZP4XIq JgmfSX9Oh//jlYrp+ypiDRJE/ks39LQfbc1q+TKY5WBbjTKX/6VSK0mGJ8i3hnfNHxgoakbEi0nzv //L2selFY+E9WoA9zzdE2Q==; Date: Mon, 08 Jul 2024 14:09:39 +0300 Message-Id: <86bk3816oc.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: (message from Jim Porter on Sun, 7 Jul 2024 20:26:17 -0700) Subject: Re: bug#71655: Eshell external commands do not work under GNU Emacs for Windows References: <86y170oifx.fsf@gnu.org> <86v824ohym.fsf@gnu.org> <86r0csnrk7.fsf@gnu.org> <8b97b729-c431-1dc2-d4d4-b988120e7de0@gmail.com> <86cyocnjkl.fsf@gnu.org> <858d2907-7ee4-da6f-cd9e-6b7bd3ba4c7e@gmail.com> <86pls8ff73.fsf@gnu.org> <875xtyyjcv.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71655-done Cc: michael.albinus@gmx.de, 71655-done@debbugs.gnu.org, james@literate-devops.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 7 Jul 2024 20:26:17 -0700 > Cc: Eli Zaretskii , 71655-done@debbugs.gnu.org, > james@literate-devops.io > From: Jim Porter > > 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 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. From unknown Sun Jun 22 07:47:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 05 Aug 2024 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 31 21:05:18 2024 Received: (at control) by debbugs.gnu.org; 1 Nov 2024 01:05:18 +0000 Received: from localhost ([127.0.0.1]:45463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6g6F-00016h-JX for submit@debbugs.gnu.org; Thu, 31 Oct 2024 21:05:17 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:56471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6g6D-000140-KZ; Thu, 31 Oct 2024 21:05:14 -0400 Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-20cf6eea3c0so13152455ad.0; Thu, 31 Oct 2024 18:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730423048; x=1731027848; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=U6XDQdRq/8mADvH2XTxL0c0xprUgN9H+PEZyh6a/pnA=; b=DB3AolU96JBrr1TMraH+tFLpdymWgqVw8JExAWFuJxQH1Ny6Kj4DM+W3M0eId6BlmF UxPBv0rEqqKNx4wZ+dXzCat8ngubzbNkjkbuvp2Np1zk33jOdMirRcGrZBaJ2JyuQNsL Nxefyo2Rnm0tuEoCtNbyPwoXD3Lm0W/BP8G14iuwFNPItMnIzK0K4Ygkyvv6Z211iLf/ 7oCHxaWy5XOnr0JYQ6aWjV9yDySwdLraQVLUAoZdrfFMKpshaVewcRtHgBLkCWu9ltdB x79dLG7Ev4TNbnO/G2Ob9jcIMMVI/Y2QxjqZ+fGKnBGJLuSq1nFKZsTYUVO9L95xFJHW usXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730423048; x=1731027848; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=U6XDQdRq/8mADvH2XTxL0c0xprUgN9H+PEZyh6a/pnA=; b=Apfu/rkwwyqYdT1M2XXjAPBTIYxM2nQPGRM+s/lQGvi6LB7Ic1y77A1HoAReEnZ9wK zFeIecilTXuyonelJyx3R+M0btryoye4iQz4nTSVL/tBTx1M0ZH78D4EA8e4ndnH7LDr d4heKh2yV9LPQl+MjhPz+dYxGpvl1/Bf5ytCmvJD/HAVLIN2z8zCZe8rG/BIvIOCphHv OHYdA/PhIRwNx0F5Iy5eOxVP9XipJprOrgcNuDd0MsYSnjqRNpdC/QWPqwJ9QebQ16XO PkHzg8woKA+gi7VpgdFatxMWXYeFHvmmmfxNikqAjSDijNPepdeWEaphgVX3eU/pzc1z /slQ== X-Forwarded-Encrypted: i=1; AJvYcCU+WTnsl9ISLszqKl8A/kiNK+iN7NB2uktik2/XseAdssieKCxrR1U9bcmD+4mGlfMqPZjdHg==@debbugs.gnu.org, AJvYcCWJnr8kenMJsvuqWgEPFo58eRUSUB/96RR2laHELd0TvOqJUtw+SXvcK360C6jI96wqJzfwqP/+bA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyXL7FFrU0/zi+Lc3c3WjIuXhIuv6QbU8czmP/Lvi+qt9zbLu2w cAS5AAl09Px1YOofgJ2ATcPlQut/gM0+RgzXEA5wPok3AGqYPCI8 X-Google-Smtp-Source: AGHT+IG7XX76CEZKGZ2FASlSldgysHIMMac5GziQiPr0Lr2DnDnjk/n2lQxSlG2DDe7+/yerViWigg== X-Received: by 2002:a17:902:e808:b0:20c:8f98:5dbe with SMTP id d9443c01a7336-210c6ae3d6bmr265697825ad.33.1730423047722; Thu, 31 Oct 2024 18:04:07 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-2110570ad54sm13951225ad.111.2024.10.31.18.04.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Oct 2024 18:04:07 -0700 (PDT) Message-ID: <0ea5c108-f8ca-978e-2a75-c2bc4fe441b5@gmail.com> Date: Thu, 31 Oct 2024 18:04:07 -0700 MIME-Version: 1.0 Subject: Re: bug#74150: ESHELL support for executables that are NTFS file system reparse points Content-Language: en-US To: dnym@duck.com, 74150@debbugs.gnu.org References: From: Jim Porter In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) unarchive 71655 forcemerge 71655 74150 thanks On 10/31/2024 5:18 PM, dnym--- via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > DESCRIPTION OF THE PROBLEM: > > None of the executables inside > C:/Users/Me/AppData/Local/Microsoft/WindowsApps > can be run from the command line under eshell. > > The error I receive when trying to run any of these executables looks like: > > Opening input file: Invalid argument, > C:/Users/Me/AppData/Local/Microsoft/WindowsApps/notepad.exe > > What I've been able to glean so far is that these executables, all of which > are 0k in size, are in fact NTFS reparse points which contain metadata > that is supposed to be read by the appropriate filter driver. Thanks for the report. This is bug#71655[1], which is already fixed in Emacs 30, so marking as a dupe. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71655 From unknown Sun Jun 22 07:47:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 29 Nov 2024 12:24:18 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator