From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=3.0 tests=BODY_8BITS,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_WEB,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 083B31F44D for ; Wed, 3 Apr 2024 14:32:38 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=case.edu header.i=@case.edu header.a=rsa-sha256 header.s=smtp-primary header.b=X8PBFYle; dkim=pass (2048-bit key; unprotected) header.d=case.edu header.i=@case.edu header.a=rsa-sha256 header.s=g-case header.b=fZKC8OZK; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2BE98384601F for ; Wed, 3 Apr 2024 14:32:37 +0000 (GMT) Received: from mpv-out-cfd-1.case.edu (mpv-out-cfd-1.CWRU.Edu [129.22.103.196]) by sourceware.org (Postfix) with ESMTPS id 57A223858401 for ; Wed, 3 Apr 2024 14:32:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 57A223858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=case.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=case.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 57A223858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.22.103.196 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712154734; cv=none; b=XxErvVGqJypFkSuc72GOhBM/lLpvRom7ACHYm0rbJZDbttP1A4l4V9hSUhhqr+iZRkodBUS8orxQ0Bngd3BBKJLSfq96IsfS2ozEFpVH2CzCQ/5YPsr2gNjbtlmfIFeqJfDtEOFbk0cbj6sGiiFOXUDVoC4fuRxFuSORdPKQSAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712154734; c=relaxed/simple; bh=s7uunLg9n2yGhi1lRyViY2Mq54JVWz56EogT7HWIbH8=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=OyVEhlhiE3VCVqbCzFQa8/7iXo3rY2CE+4RkYxoOG5rEYquQSujhUohkQ716VDNq48LyE6ESRObcaEY/kj7UMwSVyIAQD3DZJBKrwfbfCD+CT2KZttv+ZL8H8bq/O0uS/oF2Vkd80UdaQQvUoXX4dQdDSHjF+X+zBIl6Bl0zUUE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mpv-local-cfd-1.CWRU.Edu (EHLO mpv-local-cfd-1.case.edu) ([129.22.103.203]) by mpv-out-cfd-1.case.edu (MOS 4.4.8-GA FastPath queued) with ESMTP id CCY21376; Wed, 03 Apr 2024 10:32:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=case.edu; s=smtp-primary; t=1712154731; bh=cPK159z/TfoJkFfSxof1qpqTPEMexu6LaSS8ejiFJNM=; l=3161; h=Message-ID:Date:MIME-Version:Reply-To:Cc:Subject:To:References: From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=X8PBFYlenjP9AkLx73rjCuH9ml4RWJzeQsOP9al0Vo33xqRPm0lRp+epX6G6fId+0e nBX7UVJedPhjIO+zV6P8QbmWOQKQ1U520Ir8sn0kAPz2FA/SayaWUMPHTAj3+xJT7fG DcQpgXxFT1pjG8qwnTSL+cQ+NBY/zYGH5nJHTA4dfYuz+LTU5qLbSy70xUqhw41Hoex c8uK/GkPVvwROme7hifAdAT4v/fIqcRq9ypg7zk2YY2vboMqViteI/d6AR0Tn0gtoKW /ARdRK1v8mAOuU8JPw2nmnVTHWbhIOYg3y2gT/a9tA9QmrRJjhxsP/vei8Vhnw9uiEc OOjUABlQ== Received: from mail-qv1-f71.google.com (EHLO mail-qv1-f71.google.com) ([209.85.219.71]) by mpv-local-cfd-1.case.edu (MOS 4.4.8-GA FastPath queued) with ESMTP id DKB24823; Wed, 03 Apr 2024 10:32:11 -0400 (EDT) Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6992e6cb9a6so1003766d6.3 for ; Wed, 03 Apr 2024 07:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=case.edu; s=g-case; t=1712154731; x=1712759531; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:cc:reply-to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=cPK159z/TfoJkFfSxof1qpqTPEMexu6LaSS8ejiFJNM=; b=fZKC8OZKdSGhLA8nBObILPwGw5KlVOMYfIr68Z2SQgWt/hg2W/FobBdqPu2/qSn01v UN2b0YVQ6W6nI3LD/FHFxODtAR+dYotjnJMJxU90XcMoIuMEovhfb2l6VZAiHpFozk6X kT4w9lbtqsg5BliZDD6N54aR1NQ4WwT7WuSMdgEV6xAw/Ib6Z5zy39F9GKznsX6nBCbQ keP2ZNZ8wUXlvwXh8BcuouqWlEqaQ05JDp8QrXvHa/LBh29KR3/oE/EjwDPqTe172K7e 6EhtXrrT4UyTrca75AxCuofEGik1OA/84qrhIMbH2NkvnxvOe0gfbjp9mIC9gdko+eu8 /4DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712154731; x=1712759531; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:cc:reply-to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cPK159z/TfoJkFfSxof1qpqTPEMexu6LaSS8ejiFJNM=; b=eXG77JrPeEi/xrOcwoYxFRMWle00DS6ihnE/CRTb2He59DQWn76vmGNCSM4akXaFWt NkyC8zrI45kX6bAwz/aMr9jvAgtNLFaEQkr1Ec4BUL/TWOB5HX0tgzh01u9uEw+ars4y arepvPd2sjVh3EwcIa7pt37wAPAn4kX/fUiDHPeUKwYzHFbm3uKmSIdYgOfXbT1s0qAn g7PybpX07FZfmGWGhKjMr5N9l+gm5FuwqR+MalHU/45Tigr1WOBZU1FHa6KubH5bKuQ6 H6WbNl1jY0urOhntB1xDnqmgZ+nnue0q6vFgWv3sKu2TeKepEED8MHxEr7vev5aFTsc5 mD9g== X-Forwarded-Encrypted: i=1; AJvYcCW7uPK1QUsEUc9uPqZyivS5QqpsdWLzJPMB5nBzXVNM1KNfzWdw0pcbTq4yn/kMZ9euJkAmtoevf6nxfSPV9d5GOHDD2DZXJkKP X-Gm-Message-State: AOJu0YwnQcL9FCSycNCpch0gSCKztYKe/icAgFUoNSqzoyqcLsYC9F5f nSMuTaf2divu5NhSeKi+rHL6cIQ+w2na2Li00oZIBDb33bCBuUXMhvW6dpkNiVy54/CKS1DPmr9 mO4f99wKyh14FS/9bYbFVtvRzscznv4CGn6MmHCWdWHRa0koXZ+bBkiXO+XU= X-Received: by 2002:ad4:4f31:0:b0:696:a386:9ee with SMTP id fc17-20020ad44f31000000b00696a38609eemr2840213qvb.8.1712154730747; Wed, 03 Apr 2024 07:32:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFtcssuQw2JkGgxFBKsB33nC+sVYCHdtMYIjtE++KlblC1ba2iYy37zavXc0SotCe6RQs0y1g== X-Received: by 2002:ad4:4f31:0:b0:696:a386:9ee with SMTP id fc17-20020ad44f31000000b00696a38609eemr2840194qvb.8.1712154730405; Wed, 03 Apr 2024 07:32:10 -0700 (PDT) Received: from [129.22.8.211] (caleb.INS.CWRU.Edu. [129.22.8.211]) by smtp.gmail.com with ESMTPSA id h6-20020a0562140da600b006986fc6582dsm6366768qvh.57.2024.04.03.07.32.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Apr 2024 07:32:10 -0700 (PDT) Message-ID: <2791ad90-a871-474d-89dd-bc6b20cdd1f2@case.edu> Date: Wed, 3 Apr 2024 10:32:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chet.ramey@case.edu, bug-bash , libc-alpha@sourceware.org Subject: Re: Examples of concurrent coproc usage? Content-Language: en-US To: Carl Edquist , Zachary Santer References: <9831afe6-958a-fbd3-9434-05dd0c9b602a@draigBrady.com> <317fe0e2-8cf9-d4ac-ed56-e6ebcc2baa55@cs.wisc.edu> <8c490a55-598a-adf6-67c2-eb2a6099620a@cs.wisc.edu> <88a67f36-2a56-a838-f763-f55b3073bb50@lando.namek.net> From: Chet Ramey Autocrypt: addr=chet.ramey@case.edu; keydata= xsDiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0gQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxbOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ== In-Reply-To: <88a67f36-2a56-a838-f763-f55b3073bb50@lando.namek.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mirapoint-Received-SPF: 209.85.219.71 mail-qv1-f71.google.com chet.ramey@case.edu 5 none X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A742F8D.660D6121.001D, actions=spf tag X-Mirapoint-IP-Reputation: reputation=good-1, source=Fixed, refid=n/a, actions=tag X-Junkmail-Status: score=8/90, host=mpv-out-cfd-1.case.edu X-Junkmail-PrAS-Raw: score=8/90, refid=2.7.2:2023.6.26.145126:17:8.707, ip=, rules=__YOUTUBE_RCVD, DKIM_SIGNATURE, __X_GOOGLE_DKIM_SIGNATURE, __X_GM_MESSAGE_STATE, __X_GOOGLE_SMTP_SOURCE, __HAS_MSGID, __SANE_MSGID, __MSGID_HEX_844412, DATE_TZ_NA, __MIME_VERSION, __USER_AGENT, __MOZILLA_USER_AGENT, __HAS_REPLYTO, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __TO_MALFORMED_2, __MULTIPLE_RCPTS_TO_X2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __TO_GMAIL, __HAS_REFERENCES, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __MIME_BOUND_CHARSET, __CTE, CTE_8BIT, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC2, __RCPT_DOMAIN_NOT_TO, __REPLYTO_SAMEAS_FROM_DOMAIN, __DKIM_ALIGNS_1, __DKIM_ALIGNS_2, __FUR_HEADER, __ANY_URI, __URI_MAILTO, __URI_WITH_PATH, __URI_ENDS_IN_SLASH, __URI_NO_WWW, __HIGHBITS, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: chet.ramey@case.edu Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org On 3/14/24 5:58 AM, Carl Edquist wrote: > HOWEVER!!! > > Unexpectedly, the new multi-coproc code seems to close the user shell's end > of a coprocess's pipes, once the coprocess has terminated.  When compiled > with MULTIPLE_COPROCS=1, this is true even if there is only a single coproc: > >     $ coproc WC { wc; } >     $ exec {WC[1]}>&- >     [1]+  Done                    coproc WC { wc; } > >     # WC var gets cleared!! >     # shell's ${WC[0]} is also closed! > >     # now, can't do: > >     $ read -u ${WC[0]} X >     $ echo $X > > I'm attaching a "bad-coproc-log.txt" with more detailed ps & ls output > examining the open fds at each step, to make it clear what's happening. It's straightforward: the coproc process terminates, the shell reaps it, marks it as dead, notifies the user that the process exited, and reaps it before printing the next prompt. I don't observe any different behavior between the default and when compiled for multiple coprocs. It depends on when the process terminates as to whether you get a prompt back and need to run an additional command before reaping the coproc (macOS, RHEL), which gives you the opportunity to run the `read' command: $ coproc WC { wc; } [1] 48057 $ exec {WC[1]}>&- $ read -u ${WC[0]} X [1]+ Done coproc WC { wc; } bash: DEBUG warning: cpl_reap: deleting 48057 $ echo $X 0 0 0 (I put in a trace statement to show exactly when the coproc gets reaped and deallocated.) I can't reproduce your results with non-interactive shells, either, with job control enabled or disabled. > This is a bug.  The shell should not automatically close its read pipe to a > coprocess that has terminated -- it should stay open to read the final > output, and the user should be responsible for closing the read end > explicitly. How long should the shell defer deallocating the coproc after the process terminates? What should it do to make sure that the variables don't hang around with invalid file descriptors? Or should the user be responsible for unsetting the array variable too? (That's never been a requirement, obviously.) > It also invites trouble if the shell variable that holds the fds gets > removed unexpectedly when the coprocess terminates.  (Suddenly the variable > expands to an empty string.)  It seems to me that the proper time to clear > the coproc variable (if at all) is after the user has explicitly closed > both of the fds. That requires adding more plumbing than I want to, especially since the user can always save the file descriptors of interest into another variable if they want to use them after the coproc terminates. > *Or* else add an option to the coproc keyword to > explicitly close the coproc - which will close both fds and clear the > variable. Not going to add any more options to reserved words; that does more violence to the grammar than I want. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/