From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29027 invoked from network); 7 Nov 2022 08:44:01 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2022 08:44:01 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1667810641; b=sII3i3mh9DNC3vjUnPQdk3ddbyC1zPPRSmJzvEkCaYXo0zhseofyC9hTaNyGvFehuHYKV8o6Sy Hr0ExhM3jktli+tI6G1gXQqtz2JEgti3Li9ApWkUNI4UyNskdD3pf3E+u7CXHMuQEJlhbNLBvQ Wxen6gXuNsuBrDON4dgySuc6qBRC8/P2302QPgseQS+rZi5fYsNR1cKz0FzMpatYPIvjGUZ7Us gaUSWzzU6zhoKxYWEY3HxmQv+01OwhQbLXZ1f+7DDMwZnQdh5R5v4wYFakZ49PaX4y6CGl5lR/ v/iIeiUHBRIRIgnHmQy/6ie031gSC/4f5irL8NpygmnUMw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (snd00002-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.2; dmarc=none header.from=kba.biglobe.ne.jp; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1667810641; bh=Ng8reEKbWBK7UNSn8i89Gwdsrbl2Er571XtdL3thaZw=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Message-ID:In-Reply-To:To:References:Date:Subject: MIME-Version:Content-Transfer-Encoding:Content-Type:From:DKIM-Signature; b=H64BbDHvD2IneVlIfB+xnSXc85J2EsOhaf9NdRZv2deU1pXysafjIE65T+JMmQYPSiTflVaPng II886v4/ShyMKzbUr396X23ZVD1s3wOFNELJX6HDom7di7ie70acBaDLRveg6dFJK16q5V8XSO M52+cEtXyt8mRgNYBTYf0/2ZTxYs+EDZGp/OxJ8uAeIYzN3RqmPHHu1pB0LMGTYWtZyB2y0nsu qdBCF18LUzMpjl2eK5KwJPzuYDpvrl2hjUDEGmH2KATeaTwVbgd9IeRfgNdu7xB8jcwY/+i8uy a6/ukRI04eWZWwBPGyPgbwQjGsudJWCxB/RGKSlTbyo9cw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-Id:In-Reply-To:To:References: Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=ZAYJb7RpTVg5v7yivc5kldsse1+hy128E/AqaNnIypo=; b=cIjUh/y70Bufge10Nf6heYfgXa TmW5NTcvZwqbZRedgXotPdiQQ8oPitnXMDQ3DYaOX/JuOL8pjkghp7NwUf/ZDBAA8nMn1WKt2n74H wdzRj5j8SmFKzym5JJVC2pNNp7Ra7rw1v/mggmUih2Q07bcE4jSTDW7maeim531I070mzKpeKs7/M vfNdflFdLx/OzhKKrRHkRpniCyhnHUCx8+T0vt46fjQec5ZnaqrzRi0jreWv7NkoA5aLxfynLh+pA LY6wzUW2/6WWqIM3kw3GQxW109rY2Lyqoe0nskqoSy9vBSkubMKQ+uM4i7HWYA9dZzWDBSUZ/XiQ4 INcuOKtA==; Received: by zero.zsh.org with local id 1orxjb-00075o-Qd; Mon, 07 Nov 2022 08:43:59 +0000 Authentication-Results: zsh.org; iprev=pass (snd00002-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.2; dmarc=none header.from=kba.biglobe.ne.jp; arc=none Received: from snd00002-bg.im.kddi.ne.jp ([27.86.113.2]:20065 helo=dfmta0005.biglobe.ne.jp) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1orxj0-0006mE-2h; Mon, 07 Nov 2022 08:43:23 +0000 Received: from mail.biglobe.ne.jp by omta0005.biglobe.ne.jp with ESMTP id <20221107084315374.HUES.56390.mail.biglobe.ne.jp@biglobe.ne.jp> for ; Mon, 7 Nov 2022 17:43:15 +0900 From: Jun T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [PATCH] problem with 'ls | less' shell function Date: Mon, 7 Nov 2022 17:43:14 +0900 References: <2FE96386-2D04-434F-AD2F-F08356B1AE04@kba.biglobe.ne.jp> <7BB37CE7-16A2-4079-956B-802E3FB4DC82@kba.biglobe.ne.jp> To: zsh-workers@zsh.org In-Reply-To: Message-Id: <0A744179-81FA-4405-857D-6FFBE8F8FA1E@kba.biglobe.ne.jp> X-Mailer: Apple Mail (2.3445.104.21) X-Biglobe-Sender: takimoto-j@kba.biglobe.ne.jp X-Seq: 50898 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: > 2022/11/07 4:12, Bart Schaefer wrote: >=20 > On Fri, Nov 4, 2022 at 5:09 PM Bart Schaefer = wrote: >>=20 >> Second patch attached, replaces the one from workers/50862. >=20 > This "works for me" so I'm going to push it to encourage wider = testing. [1] ( zsh -fc 'print a few words; /bin/sleep 10'; ) [2] { sleep 10; sleep 11; } | { sleep 20; sleep 21; } [3] dir () { ls | less; }; dir Now both ^C and ^Z/fg fork for [1], ^C works for [2], and ^Z/fg works for [3] ({3] can't be killed by ^C but it's OK). But ^Z/fg still doesn't work for [2]; the pipeline never finishes. This was not working in zsh-5.8.1, zsh-5.9 and zsh-5.9.1-test (before worker/50874), so this is not a regression. worker/50803=E2=81=A9 > 2022/10/22 6:22, Bart Schaefer wrote: >=20 > On Fri, Oct 21, 2022 at 12:41 AM Jun T = wrote: >>=20 >> The subshell have missed the SIGCHLD? >=20 > The subshell will never get the SIGCHLD, because it is a sibling of > the pipeline, not its parent. Do you mean the subshell for the right hand side of the pipe? In the case of [2], the main zsh (zsh0) always fork() a subshell (zsh1) for the left hand side of the pipe, and zsh1 fork/exec 'sleep 10'. By hitting ^Z, zsh0 fork() another subshell (zsh2) for the right hand side of the pipe, but it seems zsh2 is not causing the problem. After 'fg', zsh1 (not zsh2) is using 100% of a CPU core, and when 'sleep 10' exits it is left as "defunct" (not waited for). Strace output suggests that zsh1 does not receive SIGCHLD when 'sleep 10' finishes. Maybe SIGCHLD is blocked?? (I'm not sure). zsh1 is repeatedly calling hasprocs(list_pid_job) at line 1790 in exec.c: 1789 if (!updated && 1790 list_pipe_job && hasprocs(list_pipe_job) && 1791 !(jobtab[list_pipe_job].stat & STAT_STOPPED)) { 1792 int q =3D queue_signal_level(); 1793 child_unblock(); 1794 child_block(); 1795 dont_queue_signals(); 1796 restore_queue_signals(q); 1797 } When zsh1 is executing this code, thisjob=3D2 and list_pipe_job=3D1, and hasprocs(list_pipe_job) returns 0 because jobtab[1].procs is NULL. I guess 'sleep 10' is in thisjob. If I blindly replace the line 1790 by 1790 list_pipe_job && then 'sleep 10' does not left as "defunct" and the pipeline finishes = when all the sleeps exit. But zsh1 still uses 100% of CPU before 'sleep 10' exits (replace 'sleep 10' by 'sleep 30' to see this more easily), so this is obviously not the correct solution. # I haven't yet understood (and maybe will never understand) the # list_pipe_xxxx.