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 08:57:37 -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> <83v8qj8a2y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------464AAB63780F1D17576D482D" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18492"; 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:00:01 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 1oQWJs-0004fw-UZ for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 18:00:01 +0200 Original-Received: from localhost ([::1]:47026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQWJr-0007bA-F7 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 11:59:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQWHe-0005tY-89 for emacs-devel@gnu.org; Tue, 23 Aug 2022 11:57:42 -0400 Original-Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]:35414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQWHb-0005W7-Ax; Tue, 23 Aug 2022 11:57:41 -0400 Original-Received: by mail-pj1-x1033.google.com with SMTP id m10-20020a17090a730a00b001fa986fd8eeso17683921pjk.0; Tue, 23 Aug 2022 08:57:38 -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=t8yKYl91JbKe6JhChPK6MDbILcU1UEnq/BtwTwEfmiU=; b=Ogw9T/zSiBzHs6GBVo2WOwl6dV8PIpWHXzkHya6q1KALQ4ajNsZyc3lrNyXX821jeH V/AVLXuic4FcYCs3/VZ1RVJWXcKIcG5jzMYTlIjjAyLjLE5oQVthR6EVHEivHHySUGSJ KtvBjknBsBMkyQQELXV537jTJhq9iuC+T4qC5lktVv+XvyDi8N7Qkdu+rmBGnJII/0/i SfrQre7wJvJ2s7sTRZi/SdnLfNjWEzbk4E6qyCgF9nmh0dCBOUg56i2XuhQeOTDiRAX1 rTBfKWvMHH9pOrxuzYjMVw16gatXcIbyJQADCYE0nBL8EJxpZTdxIAL0NctJo4WcEPE6 uEfA== 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=t8yKYl91JbKe6JhChPK6MDbILcU1UEnq/BtwTwEfmiU=; b=eLU3+ynRx7zjhwlr4eUljK5FnQzICPayBiSsgCMU1xPPkGSSGEgF7PIYvlt1U73WHn Rx50cx0nKTkolnWOVGeojXEXnhTJwPNLd6B9btLk0TV//jPaTTnzARP5wIRc2tGStCt/ /m+YTtYPIK3p0KaCu+FjXYEzYriQbdgX2q7qWheLrSPggtiVg2plKGQ2M+dcLkQ+0c02 ckdvBtdm2EYEtE7wSB2OjDyHWSU3+O6m935GazhYA0SwQ1GPFbMd0qGW8aAZpajZC8NW NeL7HCpQeauCKPy9WkbUzQFcnyzIhaWfAf948BMSWtR8vGendoz+VsUgs2KVCik34cG3 X6bQ== X-Gm-Message-State: ACgBeo3J8DBFheppKUSF4ca+Nn2fFbybj3vQt4DV6pcIjENPSJ9oYLze p9nUmHE71IXkrWmLki9yvuXNT/+rJ/E= X-Google-Smtp-Source: AA6agR4m0CO99VrOuk8aJPuMKMEBU8rScfELsJOVb744MeEym9cS+chkqTKZX2+Eq5XBQpGCVP0jHQ== X-Received: by 2002:a17:90b:1194:b0:1fa:c41a:59c0 with SMTP id gk20-20020a17090b119400b001fac41a59c0mr3923568pjb.165.1661270257378; Tue, 23 Aug 2022 08:57:37 -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 p127-20020a625b85000000b00536bbfa4963sm3960961pfb.139.2022.08.23.08.57.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Aug 2022 08:57:36 -0700 (PDT) In-Reply-To: <83v8qj8a2y.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=jporterbugs@gmail.com; helo=mail-pj1-x1033.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:293898 Archived-At: This is a multi-part message in MIME format. --------------464AAB63780F1D17576D482D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/23/2022 4:37 AM, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, emacs-devel@gnu.org >> From: Jim Porter >> Date: Mon, 22 Aug 2022 20:53:47 -0700 >> >> 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. > > So you basically assume that _any_ problem in the pipe was due to > SIGPIPE? That could be too optimistic: it could be due to something > much more mundane and unrelated. (Technically Eshell assumes that any error raised from 'process-send-string' should *break* the pipe.) To be more cautious, we could say that we should only break the pipe if we get an error *and* the process we're writing to has terminated. See attached. >>> 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 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. The goal here is just to tell a process that the thing it's writing to is gone, and that it should give up. This is more complex than usual because of how many steps Eshell goes through: some process -> 'eshell-insertion-filter' process filter -> 'eshell-output-object' -> 'process-send-string' to another process Then, if 'process-send-string' signals an error, we need to relay that back to the original process somehow so that it stops (or possibly does something else appropriate). >>>> 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? > > Looks OK, but are you sure about the "128" part? shouldn't it be 256 > instead? And perhaps explain why you add 128 (or whatever). I think the idea is that it's setting the high bit of an unsigned 8-bit value. I'm sure that the final number (141) is right for GNU/Linux at least: $ yes | head; echo ${PIPESTATUS[0]} ${PIPESTATUS[1]} y ... 141 0 I tweaked the comment to explain this number in terms of "setting the high bit", which I hope should be clearer. >> 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". > > But we can do that, right? The information about the exit status is > available to the SIGCHLD handler or a similar interface. Yes, we could. Nothing in process.c would have to change to support this; it's just a limitation of how Eshell is programmed. In a pipeline like "yes | head", the 'eshell-last-command-status' of "yes" would be 141, but it would then get overwritten by "head"'s status (0). Eshell would need to track those in a list or something. --------------464AAB63780F1D17576D482D 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" RnJvbSA2N2MzOWFiNzJlOWQ3M2Y2ZWY0YWY3ZTVjZjExNDJjNGY2YjJhZmFiIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKaW0gUG9ydGVyIDxqcG9ydGVyYnVnc0BnbWFpbC5j b20+CkRhdGU6IE1vbiwgMjIgQXVnIDIwMjIgMDk6NTM6MjQgLTA3MDAKU3ViamVjdDogW1BB VENIXSBIYW5kbGUgJ2VzaGVsbC1waXBlLWJyb2tlbicgd2hlbiBldmFsdWF0aW5nIExpc3Ag Zm9ybXMgaW4KIEVzaGVsbAoKKiBsaXNwL2VzaGVsbC9lc2gtY21kLmVsIChlc2hlbGwtZXhl Yy1saXNwKTogSGFuZGxlCidlc2hlbGwtcGlwZS1icm9rZW4nLgoKKiBsaXNwL2VzaGVsbC9l c2gtaW8uZWwgKGVzaGVsbC1vdXRwdXQtb2JqZWN0LXRvLXRhcmdldCk6IE9ubHkgc2lnbmFs Cidlc2hlbGwtcGlwZS1icm9rZW4nIGlmIHRoZSBwcm9jZXNzIGJlaW5nIHdyaXR0ZW4gdG8g aGFzIGZpbmlzaGVkLgoKKiB0ZXN0L2xpc3AvZXNoZWxsL2VzaC1wcm9jLXRlc3RzLmVsCihl c2gtcHJvYy10ZXN0L3BpcGVsaW5lLWNvbm5lY3Rpb24tdHlwZS9taWRkbGUpCihlc2gtcHJv Yy10ZXN0L3BpcGVsaW5lLWNvbm5lY3Rpb24tdHlwZS9sYXN0KTogUmVtb3ZlICc6dW5zdGFi bGUnLgotLS0KIGxpc3AvZXNoZWxsL2VzaC1jbWQuZWwgICAgICAgICAgICAgfCAgOSArKysr KysrKysKIGxpc3AvZXNoZWxsL2VzaC1pby5lbCAgICAgICAgICAgICAgfCAxMiArKysrKysr KystLS0KIHRlc3QvbGlzcC9lc2hlbGwvZXNoLXByb2MtdGVzdHMuZWwgfCAgNCAtLS0tCiAz IGZpbGVzIGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDcgZGVsZXRpb25zKC0pCgpkaWZm IC0tZ2l0IGEvbGlzcC9lc2hlbGwvZXNoLWNtZC5lbCBiL2xpc3AvZXNoZWxsL2VzaC1jbWQu ZWwKaW5kZXggMmY3N2YzZjQ5Ny4uYTQzYWQ3NzIxMyAxMDA2NDQKLS0tIGEvbGlzcC9lc2hl bGwvZXNoLWNtZC5lbAorKysgYi9saXNwL2VzaGVsbC9lc2gtY21kLmVsCkBAIC0xMzQ3LDYg KzEzNDcsMTUgQEAgZXNoZWxsLWV4ZWMtbGlzcAogICAgICAgICAgICAgICAgICAoYXBwbHkg ZnVuYy1vci1mb3JtIGFyZ3MpKSkpKQogICAgICAgICAoYW5kIHJlc3VsdCAoZnVuY2FsbCBw cmludGVyIHJlc3VsdCkpCiAgICAgICAgIHJlc3VsdCkKKyAgICAoZXNoZWxsLXBpcGUtYnJv a2VuCisgICAgIDs7IElmIEZVTkMtT1ItRk9STSB0cmllZCBhbmQgZmFpbGVkIHRvIHdyaXRl IHNvbWUgb3V0cHV0IHRvIGEKKyAgICAgOzsgcHJvY2VzcywgaXQgd2lsbCByYWlzZSBhbiBg ZXNoZWxsLXBpcGUtYnJva2VuJyBzaWduYWwgKHRoaXMgaXMKKyAgICAgOzsgYW5hbG9nb3Vz IHRvIFNJR1BJUEUgb24gUE9TSVggc3lzdGVtcykuICBJbiB0aGlzIGNhc2UsIHNldCB0aGUK KyAgICAgOzsgY29tbWFuZCBzdGF0dXMgdG8gc29tZSBub24temVybyB2YWx1ZSB0byBpbmRp Y2F0ZSBhbiBlcnJvcjsgdG8KKyAgICAgOzsgbWF0Y2ggR05VL0xpbnV4LCB3ZSB1c2UgMTQx LCB3aGljaCB0aGUgbnVtZXJpYyB2YWx1ZSBvZgorICAgICA7OyBTSUdQSVBFIG9uIEdOVS9M aW51eCAoMTMpIHdpdGggdGhlIGhpZ2ggYml0ICgyXjcpIHNldC4KKyAgICAgKHNldHEgZXNo ZWxsLWxhc3QtY29tbWFuZC1zdGF0dXMgMTQxKQorICAgICBuaWwpCiAgICAgKGVycm9yCiAg ICAgIChzZXRxIGVzaGVsbC1sYXN0LWNvbW1hbmQtc3RhdHVzIDEpCiAgICAgIChsZXQgKCht c2cgKGVycm9yLW1lc3NhZ2Utc3RyaW5nIGVycikpKQpkaWZmIC0tZ2l0IGEvbGlzcC9lc2hl bGwvZXNoLWlvLmVsIGIvbGlzcC9lc2hlbGwvZXNoLWlvLmVsCmluZGV4IGU1OTc3Yzk1ODAu LmQ1NGJlNTVjMTMgMTAwNjQ0Ci0tLSBhL2xpc3AvZXNoZWxsL2VzaC1pby5lbAorKysgYi9s aXNwL2VzaGVsbC9lc2gtaW8uZWwKQEAgLTQ5OCwxMCArNDk4LDE2IEBAIGVzaGVsbC1vdXRw dXQtb2JqZWN0LXRvLXRhcmdldAogICAgKChlc2hlbGwtcHJvY2Vzc3AgdGFyZ2V0KQogICAg ICh1bmxlc3MgKHN0cmluZ3Agb2JqZWN0KQogICAgICAgKHNldHEgb2JqZWN0IChlc2hlbGwt c3RyaW5naWZ5IG9iamVjdCkpKQotICAgIChjb25kaXRpb24tY2FzZSBuaWwKKyAgICAoY29u ZGl0aW9uLWNhc2UgZXJyCiAgICAgICAgIChwcm9jZXNzLXNlbmQtc3RyaW5nIHRhcmdldCBv YmplY3QpCi0gICAgICA7OyBJZiBgcHJvY2Vzcy1zZW5kLXN0cmluZycgcmFpc2VzIGFuIGVy cm9yLCB0cmVhdCBpdCBhcyBhIGJyb2tlbiBwaXBlLgotICAgICAgKGVycm9yIChzaWduYWwg J2VzaGVsbC1waXBlLWJyb2tlbiAobGlzdCB0YXJnZXQpKSkpKQorICAgICAgKGVycm9yCisg ICAgICAgOzsgSWYgYHByb2Nlc3Mtc2VuZC1zdHJpbmcnIHJhaXNlcyBhbiBlcnJvciBhbmQg dGhlIHByb2Nlc3MgaGFzCisgICAgICAgOzsgZmluaXNoZWQsIHRyZWF0IGl0IGFzIGEgYnJv a2VuIHBpcGUuICBPdGhlcndpc2UsIGp1c3QKKyAgICAgICA7OyByZS10aHJvdyB0aGUgc2ln bmFsLgorICAgICAgIChpZiAobWVtcSAocHJvY2Vzcy1zdGF0dXMgdGFyZ2V0KQorCQkgJyhy dW4gc3RvcCBvcGVuIGNsb3NlZCkpCisgICAgICAgICAgIChzaWduYWwgKGNhciBlcnIpIChj ZHIgZXJyKSkKKyAgICAgICAgIChzaWduYWwgJ2VzaGVsbC1waXBlLWJyb2tlbiAobGlzdCB0 YXJnZXQpKSkpKSkKIAogICAgKChjb25zcCB0YXJnZXQpCiAgICAgKGFwcGx5IChjYXIgdGFy Z2V0KSBvYmplY3QgKGNkciB0YXJnZXQpKSkpCmRpZmYgLS1naXQgYS90ZXN0L2xpc3AvZXNo ZWxsL2VzaC1wcm9jLXRlc3RzLmVsIGIvdGVzdC9saXNwL2VzaGVsbC9lc2gtcHJvYy10ZXN0 cy5lbAppbmRleCA2MmU3ODRlOGY2Li4yMzY5YmI1Y2MwIDEwMDY0NAotLS0gYS90ZXN0L2xp c3AvZXNoZWxsL2VzaC1wcm9jLXRlc3RzLmVsCisrKyBiL3Rlc3QvbGlzcC9lc2hlbGwvZXNo LXByb2MtdGVzdHMuZWwKQEAgLTc0LDggKzc0LDYgQEAgZXNoLXByb2MtdGVzdC9waXBlbGlu ZS1jb25uZWN0aW9uLXR5cGUvZmlyc3QKIChlcnQtZGVmdGVzdCBlc2gtcHJvYy10ZXN0L3Bp cGVsaW5lLWNvbm5lY3Rpb24tdHlwZS9taWRkbGUgKCkKICAgIlRlc3QgdGhhdCBhbGwgc3Ry ZWFtcyBhcmUgcGlwZXMgd2hlbiBhIGNvbW1hbmQgaXMgaW4gdGhlIG1pZGRsZSBvZiBhCiBw aXBlbGluZS4iCi0gIDs7IFJlcGVhdGVkIHVucmVwcm9kdWNpYmxlIGVycm9ycy4KLSAgOnRh Z3MgJyg6dW5zdGFibGUpCiAgIChza2lwLXVubGVzcyAoYW5kIChleGVjdXRhYmxlLWZpbmQg InNoIikKICAgICAgICAgICAgICAgICAgICAgKGV4ZWN1dGFibGUtZmluZCAiY2F0IikpKQog ICAoZXNoZWxsLWNvbW1hbmQtcmVzdWx0LWVxdWFsCkBAIC04NCw4ICs4Miw2IEBAIGVzaC1w cm9jLXRlc3QvcGlwZWxpbmUtY29ubmVjdGlvbi10eXBlL21pZGRsZQogCiAoZXJ0LWRlZnRl c3QgZXNoLXByb2MtdGVzdC9waXBlbGluZS1jb25uZWN0aW9uLXR5cGUvbGFzdCAoKQogICAi VGVzdCB0aGF0IG9ubHkgb3V0cHV0IHN0cmVhbXMgYXJlIFBUWXMgd2hlbiBhIGNvbW1hbmQg ZW5kcyBhIHBpcGVsaW5lLiIKLSAgOzsgUmVwZWF0ZWQgdW5yZXByb2R1Y2libGUgZXJyb3Jz LgotICA6dGFncyAnKDp1bnN0YWJsZSkKICAgKHNraXAtdW5sZXNzIChleGVjdXRhYmxlLWZp bmQgInNoIikpCiAgIChlc2hlbGwtY29tbWFuZC1yZXN1bHQtZXF1YWwKICAgIChjb25jYXQg ImVjaG8gfCAiIGVzaC1wcm9jLXRlc3QtLWRldGVjdC1wdHktY21kKQotLSAKMi4yNS4xCgo= --------------464AAB63780F1D17576D482D--