From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#71655: Eshell external commands do not work under GNU Emacs for Windows Date: Sun, 23 Jun 2024 18:40:37 -0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34762"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71655@debbugs.gnu.org, james@literate-devops.io To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 24 03:42:18 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sLYio-0008sG-00 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jun 2024 03:42:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLYiZ-00023s-6Y; Sun, 23 Jun 2024 21:42:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sLYiX-00023h-HF for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2024 21:42:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sLYiX-00071B-94 for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2024 21:42:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sLYiY-0005KH-04 for bug-gnu-emacs@gnu.org; Sun, 23 Jun 2024 21:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jun 2024 01:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71655 X-GNU-PR-Package: emacs Original-Received: via spool by 71655-submit@debbugs.gnu.org id=B71655.171919330820443 (code B ref 71655); Mon, 24 Jun 2024 01:42:01 +0000 Original-Received: (at 71655) by debbugs.gnu.org; 24 Jun 2024 01:41:48 +0000 Original-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 Original-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 Original-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) Original-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) Content-Language: en-US In-Reply-To: <86pls8ff73.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287813 Archived-At: 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.)