From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: esh-proc test failures Date: Tue, 23 Aug 2022 14:37:25 +0300 Message-ID: <83v8qj8a2y.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 23 13:39:19 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 1oQSFb-0008XI-AN for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 13:39:19 +0200 Original-Received: from localhost ([::1]:41320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQSFa-0006K7-8t for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Aug 2022 07:39:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQSDj-0004OZ-8F for emacs-devel@gnu.org; Tue, 23 Aug 2022 07:37:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42432) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQSDh-0002Lo-DD; Tue, 23 Aug 2022 07:37:22 -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=bbHPRtDAYdWAoev22FBP3blavuGN96YeoRysXXUb0vc=; b=ewglLY2PslfM xcsRcQULgLfX0/XvEejrJj8cYG+BoqfYdt9YTAoAeV9wThvh7EJ6ePXb9yeA0jylI+6dTTirvv+gc HKHHqYMOK/oqXedygYrt5dTFLFf09cctorwMWLyefxZFu2RPumI2apZgscx3Qciek8VYpgPUe/4ct Q9HQ8gh6Eou1Fdj9nDI29ewheJPpxk6PjJOkcVLMHAr8I2SByHGHEIU8T4iJ+qn3HsDEOtlre+jKH u5Sds3ITewNL6yzFnlRte+lQUdbpnmOKmf5mavgPoiye9G1nGNG7Y6Vr59Yc9zEdu8JLHbjxOU7Al ptm7HZ4I2EqmSsiJ6PWXCg==; Original-Received: from [87.69.77.57] (port=4361 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQSDf-000520-CY; Tue, 23 Aug 2022 07:37:20 -0400 In-Reply-To: (message from Jim Porter on Mon, 22 Aug 2022 20:53:47 -0700) 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:293866 Archived-At: > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Jim Porter > Date: Mon, 22 Aug 2022 20:53:47 -0700 > > >> 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. 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. > > 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. > >> 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). > 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.