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: Mon, 22 Aug 2022 20:53:47 -0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------D29F86C208524E97CA8DA55F" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17110"; 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 05:56:03 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 1oQL1F-0004G0-W3 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 05:56:02 +0200 Original-Received: from localhost ([::1]:45214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQL1E-0002hd-Fn for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Aug 2022 23:56:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQKzB-0001Ds-FY for emacs-devel@gnu.org; Mon, 22 Aug 2022 23:53:53 -0400 Original-Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]:38519) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQKz9-0004ge-Jv; Mon, 22 Aug 2022 23:53:53 -0400 Original-Received: by mail-pg1-x52a.google.com with SMTP id r22so11197483pgm.5; Mon, 22 Aug 2022 20:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject:from:to:cc; bh=nQTmEZtEiwXuagth7dB/uwB9u6YQEJxZEsh0gw42cgw=; b=kJOz+w0GBISsZZOI35zC/iORYFKHATVjksUe85KrA1vhfs/IVDWtEiEexqzAakHy3E BO7ulaC33G4d/QJ6RZKZjzVmXRgjsJDKZg45MkxUdKh+gdpgjUAZbkod/vxy9Fv5ZTQe i3fTPx+RQ/rQGTRALh0AVrQmyKb5hAqCKR5NzwMzwq/dwWlxIW9FzaAIhsPRjvg+bU40 gqq4B0cGM5loXK76/LqEGkhPAsU1k3R7roZVzaKSxRl4/z5+VdkeMkGi8UKvIJ8OSHp4 QtV04PjEdlgoveAmTnHFthmhYSZen08j++zDIv8h/+XlGHnpYTed4WLaumqxogAfLGSS 5/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject:x-gm-message-state:from:to:cc; bh=nQTmEZtEiwXuagth7dB/uwB9u6YQEJxZEsh0gw42cgw=; b=wRFXXPdxaGl60Okvli1P4tBdxzT1MInvrFIzc/zgT5T1MbuHMtjSeYJvGZ44b4JhR4 emzZv7iUCUoyHXQtMS5HzjTA/rhvGofl4ZEWIAs6CBwDM5VWkmXXTEhJo/tHOySqKgTw T/5q1gQcHzSvlzaK1VsIkN8TtxE9afVr1Xt16Bp1XQn/zmAMAUw7DhJodjHXN9UZVkh4 l7d6x6T2urVhvjcsixXej7jmUOTNKoxg6e1nQ+DowmwQfcE6LuOOy267GioKekYfe9pB bc4ze8YFPD+WIc1tC+ZDmiMmRFTjUaGRar/9WDbb5DeniAwl4Ntv3ugq5TIxa+wlSj4K JDUQ== X-Gm-Message-State: ACgBeo3tZ+zpxE+weJaawrAxSaaWTxE09l7Z7YeOhl7KFyN8J/krvgJV vY+x3Jb91PFVObHvRWQoUf/5Z7l16pI= X-Google-Smtp-Source: AA6agR5XLhxbZIZAFz6TLNtlzR/h8BFUzFeFyxSOaJs2/oZpxGFmtKXciKxTWNRCMiWbeSgZeU9pYA== X-Received: by 2002:a63:8949:0:b0:429:a424:b07c with SMTP id v70-20020a638949000000b00429a424b07cmr19388801pgd.219.1661226829886; Mon, 22 Aug 2022 20:53:49 -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 y11-20020a17090a784b00b001f021cdd73dsm10721593pjl.10.2022.08.22.20.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 20:53:48 -0700 (PDT) In-Reply-To: <837d2zae3m.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2607:f8b0:4864:20::52a; envelope-from=jporterbugs@gmail.com; helo=mail-pg1-x52a.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:293841 Archived-At: This is a multi-part message in MIME format. --------------D29F86C208524E97CA8DA55F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/22/2022 7:27 PM, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, emacs-devel@gnu.org >> From: Jim Porter >> Date: Mon, 22 Aug 2022 12:23:37 -0700 >> >>>> + (eshell-pipe-broken >>>> + ;; 141 is 128 + 13 (the numeric value of SIGPIPE). >>>> + (setq eshell-last-command-status 141) >>>> + nil) >>> >>> This is non-portable, I think on two counts: >>> >>> . the assumption that the exit code is the signal number left-shifted >>> by N bits (btw, isn't N = 8, not 7?) >>> . the assumption that SIGPIPE is signal 13 (does Posix mandate that?) >>> >>> What do we expect to happen here on MS-Windows and other non-Posix >>> platforms, where both of the above assumptions are false? >> >> The only thing that really needs to happen here is that the signal is >> caught so it doesn't bubble up past this point and break things. > > How do you accomplish that? On MS-Windows there's no SIGPIPE signal, > for example. If Eshell tries to write to a process object and it fails, it gets treated as a broken pipe. Technically, it signals 'eshell-pipe-broken', but that's roughly equivalent to SIGPIPE. This is mainly so that in a pipeline like "foo | bar", if "bar" terminates, Eshell can inform "foo" of the fact; on POSIX systems, it would send SIGPIPE, but on MS Windows, it just calls 'delete-process'. This is important because we want to be sure that if you have a pipeline like "yes | head", the "yes" gets stopped once "head" is done. Eshell's implementation isn't perfect though; since Emacs uses process filters, Eshell actually sends the SIGPIPE later than otherwise expected. Still, it's probably better than hanging indefinitely. (Fixing this "properly" would probably require dramatically reworking how Emacs interacts with subprocesses, which I think would be too risky to do, since we don't want to break things in process.c.) For the actual code that raises this signal, see the end of the function 'eshell-output-object-to-target' in lisp/eshell/esh-io.el. >> The >> command status could be anything really, and I'm pretty sure Eshell >> doesn't even allow inspecting this value (yet), since it would only >> occur for a non-last item in a pipeline. (In the future, Eshell could >> offer something like $PIPESTATUS to examine this.) > > Not sure I understand completely what you are saying here, but AFAIR > writing to a closed pipe on MS-Windows will cause EINVAL errno. Indeed, it would be nice if we could force things so that an MS Windows program gets EINVAL for its WriteFile call, but because Eshell only interacts indirectly with the program's output, it's too late to do that by the time Eshell responds. >> I could expand the comment to explain that this value is >> somewhat-arbitrary and just designed to match GNU/Linux. > > Yes, please. How does the attached look? >> Alternately, if there's a way to inspect the system's conventions to >> use here (e.g. getting the numeric value of SIGPIPE for the current >> system), we could do that too. > > I might be able to help if I understand better what is needed here. Well, it depends on what we think users would expect. Currently, I don't think Eshell provides the necessary functionality to tell when the process "foo" fails (i.e. returns a non-zero exit status) in the pipeline "foo | bar". However, if it did, I think the most a user would care about is that there's some consistent way of telling what went wrong. If there were a way to determine what convention the current system uses to say "foo terminated because it tried to write to bar after bar exited", we could use that. I'm not sure this part is worth spending a lot of time on though, especially since the exit status of "foo" isn't currently accessible as far as I know. --------------D29F86C208524E97CA8DA55F Content-Type: text/plain; charset=UTF-8; name="0001-Handle-eshell-pipe-broken-when-evaluating-Lisp-forms.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-Handle-eshell-pipe-broken-when-evaluating-Lisp-forms.pa"; filename*1="tch" RnJvbSA2OWY4NGI0MTAxMzEzYWJjMDI1MTg5YjJkYmRjNTdkOWI2ZTQ4NDllIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IE1vbiwgMjIgQXVnIDIwMjIgMDk6NTM6MjQgLTA3MDAKU3ViamVjdDogW1BB VENIXSBIYW5kbGUgJ2VzaGVsbC1waXBlLWJyb2tlbicgd2hlbiBldmFsdWF0aW5nIExpc3Ag Zm9ybXMgaW4KIEVzaGVsbAoKKiBsaXNwL2VzaGVsbC9lc2gtY21kLmVsIChlc2hlbGwtZXhl Yy1saXNwKTogSGFuZGxlCidlc2hlbGwtcGlwZS1icm9rZW4nLgoKKiB0ZXN0L2xpc3AvZXNo ZWxsL2VzaC1wcm9jLXRlc3RzLmVsCihlc2gtcHJvYy10ZXN0L3BpcGVsaW5lLWNvbm5lY3Rp b24tdHlwZS9taWRkbGUpCihlc2gtcHJvYy10ZXN0L3BpcGVsaW5lLWNvbm5lY3Rpb24tdHlw ZS9sYXN0KTogUmVtb3ZlICc6dW5zdGFibGUnLgotLS0KIGxpc3AvZXNoZWxsL2VzaC1jbWQu ZWwgICAgICAgICAgICAgfCA5ICsrKysrKysrKwogdGVzdC9saXNwL2VzaGVsbC9lc2gtcHJv Yy10ZXN0cy5lbCB8IDQgLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCA5IGluc2VydGlvbnMoKyks IDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9lc2hlbGwvZXNoLWNtZC5lbCBi L2xpc3AvZXNoZWxsL2VzaC1jbWQuZWwKaW5kZXggMmY3N2YzZjQ5Ny4uMzg4NmExYzA4NiAx MDA2NDQKLS0tIGEvbGlzcC9lc2hlbGwvZXNoLWNtZC5lbAorKysgYi9saXNwL2VzaGVsbC9l c2gtY21kLmVsCkBAIC0xMzQ3LDYgKzEzNDcsMTUgQEAgZXNoZWxsLWV4ZWMtbGlzcAogICAg ICAgICAgICAgICAgICAoYXBwbHkgZnVuYy1vci1mb3JtIGFyZ3MpKSkpKQogICAgICAgICAo YW5kIHJlc3VsdCAoZnVuY2FsbCBwcmludGVyIHJlc3VsdCkpCiAgICAgICAgIHJlc3VsdCkK KyAgICAoZXNoZWxsLXBpcGUtYnJva2VuCisgICAgIDs7IElmIEZVTkMtT1ItRk9STSB0cmll ZCBhbmQgZmFpbGVkIHRvIHdyaXRlIHNvbWUgb3V0cHV0IHRvIGEKKyAgICAgOzsgcHJvY2Vz cywgaXQgd2lsbCByYWlzZSBhbiBgZXNoZWxsLXBpcGUtYnJva2VuJyBzaWduYWwgKHRoaXMg aXMKKyAgICAgOzsgYW5hbG9nb3VzIHRvIFNJR1BJUEUgb24gUE9TSVggc3lzdGVtcykuICBJ biB0aGlzIGNhc2UsIHNldCB0aGUKKyAgICAgOzsgY29tbWFuZCBzdGF0dXMgdG8gc29tZSBu b24temVybyB2YWx1ZSB0byBpbmRpY2F0ZSBhbiBlcnJvcjsgdG8KKyAgICAgOzsgbWF0Y2gg R05VL0xpbnV4LCB3ZSB1c2UgMTQxLCB3aGljaCBpcyAxMjggKyAxMyAodGhlIG51bWVyaWMK KyAgICAgOzsgdmFsdWUgb2YgU0lHUElQRSBvbiBHTlUvTGludXgpLgorICAgICAoc2V0cSBl c2hlbGwtbGFzdC1jb21tYW5kLXN0YXR1cyAxNDEpCisgICAgIG5pbCkKICAgICAoZXJyb3IK ICAgICAgKHNldHEgZXNoZWxsLWxhc3QtY29tbWFuZC1zdGF0dXMgMSkKICAgICAgKGxldCAo KG1zZyAoZXJyb3ItbWVzc2FnZS1zdHJpbmcgZXJyKSkpCmRpZmYgLS1naXQgYS90ZXN0L2xp c3AvZXNoZWxsL2VzaC1wcm9jLXRlc3RzLmVsIGIvdGVzdC9saXNwL2VzaGVsbC9lc2gtcHJv Yy10ZXN0cy5lbAppbmRleCA2MmU3ODRlOGY2Li4yMzY5YmI1Y2MwIDEwMDY0NAotLS0gYS90 ZXN0L2xpc3AvZXNoZWxsL2VzaC1wcm9jLXRlc3RzLmVsCisrKyBiL3Rlc3QvbGlzcC9lc2hl bGwvZXNoLXByb2MtdGVzdHMuZWwKQEAgLTc0LDggKzc0LDYgQEAgZXNoLXByb2MtdGVzdC9w aXBlbGluZS1jb25uZWN0aW9uLXR5cGUvZmlyc3QKIChlcnQtZGVmdGVzdCBlc2gtcHJvYy10 ZXN0L3BpcGVsaW5lLWNvbm5lY3Rpb24tdHlwZS9taWRkbGUgKCkKICAgIlRlc3QgdGhhdCBh bGwgc3RyZWFtcyBhcmUgcGlwZXMgd2hlbiBhIGNvbW1hbmQgaXMgaW4gdGhlIG1pZGRsZSBv ZiBhCiBwaXBlbGluZS4iCi0gIDs7IFJlcGVhdGVkIHVucmVwcm9kdWNpYmxlIGVycm9ycy4K LSAgOnRhZ3MgJyg6dW5zdGFibGUpCiAgIChza2lwLXVubGVzcyAoYW5kIChleGVjdXRhYmxl LWZpbmQgInNoIikKICAgICAgICAgICAgICAgICAgICAgKGV4ZWN1dGFibGUtZmluZCAiY2F0 IikpKQogICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsCkBAIC04NCw4ICs4Miw2IEBA IGVzaC1wcm9jLXRlc3QvcGlwZWxpbmUtY29ubmVjdGlvbi10eXBlL21pZGRsZQogCiAoZXJ0 LWRlZnRlc3QgZXNoLXByb2MtdGVzdC9waXBlbGluZS1jb25uZWN0aW9uLXR5cGUvbGFzdCAo KQogICAiVGVzdCB0aGF0IG9ubHkgb3V0cHV0IHN0cmVhbXMgYXJlIFBUWXMgd2hlbiBhIGNv bW1hbmQgZW5kcyBhIHBpcGVsaW5lLiIKLSAgOzsgUmVwZWF0ZWQgdW5yZXByb2R1Y2libGUg ZXJyb3JzLgotICA6dGFncyAnKDp1bnN0YWJsZSkKICAgKHNraXAtdW5sZXNzIChleGVjdXRh YmxlLWZpbmQgInNoIikpCiAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwKICAgIChj b25jYXQgImVjaG8gfCAiIGVzaC1wcm9jLXRlc3QtLWRldGVjdC1wdHktY21kKQotLSAKMi4y NS4xCgo= --------------D29F86C208524E97CA8DA55F--