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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 7EA6D1F44D for ; Tue, 9 Apr 2024 14:46:38 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=dzdrIX2B; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BFEEA38449C7 for ; Tue, 9 Apr 2024 14:46:37 +0000 (GMT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 71B653858289 for ; Tue, 9 Apr 2024 14:46:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 71B653858289 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 71B653858289 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712673977; cv=none; b=RN20uvHAdZ0+/nDgl1ErwuCls4ts91nrmNus1il5neTsLn7Qe1PuAjubaYmUOkuaoTWK3cj96wY2u3HV7XXbsf4NFXYLAaKfmBfA4AifXgkophz9Cn/pxa0Hjc88/3YkE0aN0RBAK6uqCmjXHVLqGJXEImp0HHhRm1v3CHggoRA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712673977; c=relaxed/simple; bh=deFHujHVTya4UAfEOUA0whbjpFxPycenUUCx7VAkhw8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=gG6bV+mmPLMhLZN7idkkalyiJhpnkukUHQwJYv+fCVR5V/BK2JPDfShylLvsVeT4/0iZknOOgnivz0qA8g0gAxOxCNRuu2M/ThvtCrQjRz6Q2fw4J69lTtYbbW0z1gZdzHPoFAP+6sWYRRJr99luh8MWzYKvyEGo6WW0xbJ8/ro= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a44ad785a44so672914966b.3 for ; Tue, 09 Apr 2024 07:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712673974; x=1713278774; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3nQFh20Y38bYmbmDHfM7JKkRv+S6OKfHK1SDHCiQPOI=; b=dzdrIX2BeCLd3GL1trHsZ+wllP+79y8rE5HAs460Mxw/KPtJuRjD5j0e3ssK6nLYGC giOps9pr9Dr7VcTU4OyXkHqX+9qV6+kseUSHeK5O8Ya10YhP2yZn34pl4oAyndVoQoNs o+2tGbs4A5cI7Z0EXzu4ybnEU3dryQAI4eGYvpg1qM0GVJW6q26aUn6Eq5GACVJrboIU OfqDAYsxQgnh3rffQsgkjRqoko6ucfrqKwQJV3kbrqKva90QAUw0p+5hJyHV4HsXECBr UASmdgYi7LRFFRypfGLkoJFGYTz0XyXTGTQ9GS/v6YGygSNOJulbNf1Nc32XCzCEv+2k 1HLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712673974; x=1713278774; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3nQFh20Y38bYmbmDHfM7JKkRv+S6OKfHK1SDHCiQPOI=; b=VTpSFg4fNfmfKHQMXKT2J1sCDOrEQ6NOvsOkc3OOHGzyL30zs7DWqJ674XIl6t76pf QplNjTqEX8IegBIyihffkz3A2PXiVydFy08R7VYVNikWAnIWfelnL5xQduWGTbsGPHL6 ns/PH9tDcPz1qwOjDVNpANsI6vNeRc+tput87S2QbwLeaf0zxKNZaAj4es2cy/v8vAOG GB1U4Yhl2vZ/kPpd/a0My61/bBYqWfKriGYzi+1A+YLJc7U09ED7TQoh8nQo6tbKE9Qj BIQRzdfprTZhO3CR10lF5iVHsPN8JmdfBQsXvAeWWJaG48YkzQ8htsjIXEPP6BcbIlHz GOXw== X-Forwarded-Encrypted: i=1; AJvYcCU+5wvPZq4kpVZyIsPS9BhxyH1vB6iMa2hJLLhUA2EfBCXQAdxY+ajbN6kqF6Z0LlqNMUIAc8zVHIGPKZ6gynns6zbDYxySCIej X-Gm-Message-State: AOJu0YwQXF2Rhv8rtQOxiv8hNFaI6eZwppuNIywvv/4Zh1rKc3ImJlpC 00WW6dSsOEjvr0L7dn+ov+ZeGj+EatLWUKlIAIwp7Izs/qouEFmwqjNh2BN8NEWmzg8m2SSLGdx /WOQlNA1zUdfjjZmZD8CmurPWrFM= X-Google-Smtp-Source: AGHT+IEgJ4+6e7NJnbA0n0WC0o56WItHqiuxmTFtpcKS+scK0r0sQUtw4A/Su/6bivlJchdGzj/90HrnEcJ4to0X2nM= X-Received: by 2002:a17:907:804:b0:a51:fa56:4fc7 with SMTP id wv4-20020a170907080400b00a51fa564fc7mr1344679ejb.21.1712673973900; Tue, 09 Apr 2024 07:46:13 -0700 (PDT) MIME-Version: 1.0 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> <2791ad90-a871-474d-89dd-bc6b20cdd1f2@case.edu> In-Reply-To: From: Zachary Santer Date: Tue, 9 Apr 2024 10:46:02 -0400 Message-ID: Subject: Re: Examples of concurrent coproc usage? To: chet.ramey@case.edu Cc: Martin D Kealey , Carl Edquist , bug-bash , libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org On Mon, Apr 8, 2024 at 3:50=E2=80=AFPM Chet Ramey wro= te: > > On 4/4/24 7:23 PM, Martin D Kealey wrote: > > I'm somewhat uneasy about having coprocs inaccessible to each other. > > I can foresee reasonable cases where I'd want a coproc to utilize one o= r > > more other coprocs. > > That's not the intended purpose, so I don't think not fixing a bug to > accommodate some future hypothetical use case is a good idea. That's > why there's a warning message when you try to use more than one coproc -- > the shell doesn't keep track of more than one. That use case is always going to be hypothetical if the support for it isn't really there, though, isn't it? > If you want two processes to communicate (really three), you might want > to build with the multiple coproc support and use the shell as the > arbiter. If you've written a script for other people than just yourself, expecting all of them to build their own bash install with a non-default preprocessor directive is pretty unreasonable. The part that I've been missing this whole time is that using exec with the fds provided by the coproc keyword is actually a complete solution for my use case, if I'm willing to close all the resultant fds myself in background processes where I don't want them to go. Which I am. $ coproc CAT1 { cat; } [1] 1769 $ exec {CAT1_2[0]}<&"${CAT1[0]}" {CAT1_2[1]}>&"${CAT1[1]}" {CAT1[0]}<&- {CAT1[1]}>&- $ declare -p CAT1 CAT1_2 declare -a CAT1=3D([0]=3D"-1" [1]=3D"-1") declare -a CAT1_2=3D([0]=3D"10" [1]=3D"11") $ coproc CAT2 { exec {CAT1_2[0]}<&- {CAT1_2[1]}>&-; cat; } [2] 1771 $ exec {CAT2_2[0]}<&"${CAT2[0]}" {CAT2_2[1]}>&"${CAT2[1]}" {CAT2[0]}<&- {CAT2[1]}>&- $ declare -p CAT2 CAT2_2 declare -a CAT2=3D([0]=3D"-1" [1]=3D"-1") declare -a CAT2_2=3D([0]=3D"12" [1]=3D"13") $ printf 'dog\ncat\nrabbit\ntortoise\n' >&"${CAT1_2[1]}" $ IFS=3D'' read -r -u "${CAT1_2[0]}" line; printf '%s\n' "${?}:${line}" 0:dog $ exec {CAT1_2[1]}>&- $ IFS=3D'' read -r -u "${CAT1_2[0]}" line; printf '%s\n' "${?}:${line}" 0:cat [1]- Done coproc CAT1 { cat; } $ IFS=3D'' read -r -u "${CAT1_2[0]}" line; printf '%s\n' "${?}:${line}" 0:rabbit $ IFS=3D'' read -r -u "${CAT1_2[0]}" line; printf '%s\n' "${?}:${line}" 0:tortoise $ IFS=3D'' read -r -u "${CAT1_2[0]}" line; printf '%s\n' "${?}:${line}" 1: $ exec {CAT1_2[0]}<&- {CAT2_2[0]}<&- {CAT2_2[1]}>&- $ [2]+ Done No warning message when creating the CAT2 coproc. I swear, I was so close to getting this figured out three years ago, unless the behavior when a coproc still exists only because other non-coproc fds are pointing to it has changed since whatever version of bash I was testing in at the time. I am completely satisfied with this solution. The trial and error aspect to figuring this kind of stuff out is really frustrating. Maybe I'll take some time and write a Wooledge Wiki article on this at some point, if there isn't one already. Whether the coproc fds should be automatically kept out of most kinds of subshells, like it is now; or out of more kinds than currently; is kind of beside the point to me now. But, having a builtin to ensure the same behavior is applied to any arbitrary fd might be useful to people, especially if those fds get removed from process substitutions as well. If the code for coproc fds gets applied to these fds, then you've got more chances to see that the logic actually works correctly, if nothing else.