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.devel Subject: Re: esh-proc test failures Date: Tue, 23 Aug 2022 09:38:27 -0700 Message-ID: <40db52f2-86f1-3e86-fbca-80a8be09ee66@gmail.com> References: <166036758418.2203.8730240669199078524@vcs2.savannah.gnu.org> <20220813051305.6667BC09BFE@vcs2.savannah.gnu.org> <87o7wmg0nx.fsf_-_@gnus.org> <30a7e3aa-ad52-325f-4fcd-528aade4a339@gmail.com> <838rng9kes.fsf@gnu.org> <837d2zae3m.fsf@gnu.org> <83v8qj8a2y.fsf@gnu.org> <83v8qj6iay.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 18:40:35 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oQWx9-0008cV-0T for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 18:40:35 +0200 Original-Received: from localhost ([::1]:52028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQWx7-0002hq-CU for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 12:40:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQWv8-0000sX-BA for emacs-devel@gnu.org; Tue, 23 Aug 2022 12:38:30 -0400 Original-Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]:34726) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQWv6-0003V5-Jv; Tue, 23 Aug 2022 12:38:29 -0400 Original-Received: by mail-pl1-x633.google.com with SMTP id io24so5406plb.1; Tue, 23 Aug 2022 09:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :date:message-id:from:references:cc:to:subject:from:to:cc; bh=JyGdBm3BLnrrDwq1ATm/2gMfKQEPOyFs/NantI3Lcig=; b=W8XAvbA4ip+WcZZlmgMpt9nTO/K651AO/MUA8EPEKn7QBo+Rvr/2Czm9uk11Hab9Q1 I2hvUm0LBVILQPa8UjfBAR/SO6HHBwY48hYjCm3mnyRRs+zHLuXSGFiGpaY1hvhMQxle SCzPR0430yjLwyMakGXZCRQR/43RSpdRWgCpeMwWtHEIMsuQCKMqMC3q9haj8MPFR2GT 2wK+n4WcmkBqs7koD6EfVcmbbDxUFFl42pOgGce6BWarnhvHkb3fZehvDrPlS5dd7gMO Oi4L530xwy9Xfw4Xk1Wch1izl/YXPhO7NjbWLfK4td4fdhUQ2Yt1q/CHF9wb/AL2PtAT FsOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :date:message-id:from:references:cc:to:subject:x-gm-message-state :from:to:cc; bh=JyGdBm3BLnrrDwq1ATm/2gMfKQEPOyFs/NantI3Lcig=; b=Bb/vuxeoSRT61fDXHRrxXT/dpYOIxFL6kbqjAAXAugNIQWTxOb9SS1FPbIKk8lV7be OcR7tsXMHvgDjlE7GB5iaU3dLHn/kCddLrmmETCexxKoFz4UZ10n3uhCErv7au1zNEL4 898rBxF9sWlNLIQotlSKEGDGBOMG4qNM3FwJrwbMW2nzCcgq/gZ+aft8Z9EGGe1SD0ME 2hUWKJL0QcsJPcGHZJxB+5RVbrj6zEgUHvjsy6wds6JRXoNcqWiTQ/sn+HbTfQX9/KzL 02IlQUXYQYUI4QlumVmXNcHf5Nzd6u/6A6Yz6KG+zSbrpvsGh47oLMBcpcTphL2Miftv IrMQ== X-Gm-Message-State: ACgBeo19WTstWtAhHBa/PL49cyoz7WSwKfq/vNyzzE3kWwWAp7y6daly el3cVYwaBJxtdsS/AjG1h/ME4fs4NR4= X-Google-Smtp-Source: AA6agR7ed8PZxaKQ9xOqYkSLGvnKB5i13Px3RCO7SEnduBW3dXx0NdCiDuzMNY76rKvgMUI3yjy9ng== X-Received: by 2002:a17:902:cf42:b0:172:ed15:ee with SMTP id e2-20020a170902cf4200b00172ed1500eemr9396120plg.149.1661272706588; Tue, 23 Aug 2022 09:38:26 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id j9-20020a63ec09000000b00427564b6b57sm9498048pgh.7.2022.08.23.09.38.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Aug 2022 09:38:25 -0700 (PDT) In-Reply-To: <83v8qj6iay.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2607:f8b0:4864:20::633; envelope-from=jporterbugs@gmail.com; helo=mail-pl1-x633.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293906 Archived-At: On 8/23/2022 9:22 AM, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, emacs-devel@gnu.org >> From: Jim Porter >> Date: Tue, 23 Aug 2022 08:57:37 -0700 >> >>> I don't think I follow. When the write fails, we get an error and >>> propagate it all the way up to the caller. >> >> If we signal an error in a process filter, does Emacs inform the process >> that wrote that data of the error? My tests showed that it didn't, but >> maybe I was doing something wrong. > > Why are you talking about the process filter? Does that filter call > process-send-string to write to the next process in the pipe? If so, > it should inform Emacs about any errors in writing. Yes. For the pipeline "foo | bar", the process filter for "foo" (eventually) calls 'process-send-string' for "bar". The code in Eshell is designed to do what you say. The manual says, "If an error happens during execution of a filter function, it is caught automatically, so that it doesn’t stop the execution of whatever program was running when the filter function was started." As I understand it, since we *want* to stop execution, that means Eshell needs to be responsible for notifying "foo" if it failed to write to "bar". Eshell does that by signaling a special error ('eshell-pipe-broken') when writing to "bar" after it terminated[1]; then, the process filter for "foo" can catch that and send a SIGPIPE signal[2] to "foo". >> The goal here is just to tell a process that the thing it's writing to >> is gone, and that it should give up. > > That cannot happen, because Eshell is in-between. Instead, it is > Emacs (Eshell) that should see the error, and deliver a signal to the > relevant process if needed. Then I think we're in agreement, since that's what Eshell currently does. (My sentence above was just trying to say that, *somehow*, Eshell needs to be sure that the relevant process is informed of the error. Delivering a signal is how Eshell does it now, and I think that's ok.) [1] That's the behavior in my new patch. Previously, it signaled 'eshell-pipe-broken' on any write error to "bar". [2] Or some approximation of this on systems without SIGPIPE.