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 [8.43.85.97]) (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 81BF21F44D for ; Tue, 9 Apr 2024 03:45:05 +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=RuYkL8m3; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F03C3858CD1 for ; Tue, 9 Apr 2024 03:45:04 +0000 (GMT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 67E703858CD1 for ; Tue, 9 Apr 2024 03:44:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 67E703858CD1 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 67E703858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::536 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712634283; cv=none; b=NqyZZ+TLMsT3zdtKiccrBNi/zd2XoFiF5Snl20KU+dNJ/Oi+slMGUhQJ5bT861emxQY70dDylmp1jmDjWyf/xfd89BAZpNEQxojjar6GeyLZQAY/mtKlN7mt5QzKcRdGRvWwCdMfONaoUUlBXPqoQ8mlrEJB9EWhuEP5TM9npis= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712634283; c=relaxed/simple; bh=xUZ6jr2zCkBq95skYWoW3cGbhVIkigepRwb23PCwhYE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=BTGstYC4dBy4ZnOvv1C0PZftqZa8YciEZXGUH/swXnb5ruKw2CQAdQJy/IA1bi30aJI5JVyAaj26QrU24TKVc1yDjhJbJHjZXx7lCxE8zj5K3atWK8rjcHfGKjWDpJ+ECoO8Bvk5sYyaVaeMkHCvWNlEUhSisr5Met3alN+MH+A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56e449187fcso2670959a12.3 for ; Mon, 08 Apr 2024 20:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712634280; x=1713239080; 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=xUZ6jr2zCkBq95skYWoW3cGbhVIkigepRwb23PCwhYE=; b=RuYkL8m3iVO40kW9b07Ma8AWnMxIEwNYev20ZdqAT7qCG+NXG/BWBwLkP+yng5+Mgo u5N5WCX3eFm6it+u3kzdhsCx0z++UQ5bHWjqRbHU9GFDAr6j7h3tFRGxO5IW42akGzXy Gw7FPOmmwej36IkcWwTtD2DqKnEjZfzdWtWKJN56ubO63vJr+3dEcryI64AWLChsfhdH 3zXYcOBwjnU22wrx77aYX2Od5v66+3lfk2K5/atyyq/ptthF1KQVO4tMg5x5sL53iT+F xLM0nDdCCE7ADxSMBOOU3IEDTf4gR1RAE6iXmZCX5qifJunpUaaJdrxNoM9iVNcyk/zk xILw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712634280; x=1713239080; 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=xUZ6jr2zCkBq95skYWoW3cGbhVIkigepRwb23PCwhYE=; b=oqO1FvvuwFP7VbodUeUR9UGEYosXoXRsg4q1cKW4VqziJuGM5ZT2JkcdNpjkUNM8Ov 8pvxnKx8s0MokHE3bzMzIZlvDo+e+/Z0Q99gplzV+yeKhLEEwVECszV/f3ubuuRBHrHM rFC8cCLeW0VZdgU+BcXfWhG2+i8YJLZOePcmV3T0wV+Dhjo01ZpIF7rrRrp/biptKMVQ FYgZMh0fQ1yHYI0kftpPtzWEkq3ttxp7ym54KRJGo0LeUhCmNAopmoCFhPZUjSdbTJqG yjJO9DTXXGtTw2ZS7E6CXv0R5dXu+pQAYkLr0AEp+HU7xXJgg/n/3kI9y1VAO0/vTrWq KelQ== X-Forwarded-Encrypted: i=1; AJvYcCW/GefIGOrLYIMtseJr7vjqi5/v5zheVKDqUPBYK4mQYIVusXzG5etpuE4IA6puCziME6NkMPNvWPitbsM9s4LuYMn9eCPRUxDY X-Gm-Message-State: AOJu0YyT+1mFlPgdvma+vQosp/pFIz92wYRnMfmJhIFb98a1GnO+YxaU 0p2/C2D8/pG/b++SLGrP8z2Oxon79i+JsK3I/COb/vlbbSCkT3/N0QruPph1y68Wjw0E2X3TfgX ov0c78wFZ1HeztBgrFabHX80btlU= X-Google-Smtp-Source: AGHT+IGDXgjbXjeGiWZVlXuHnUnkwu2+LmqB7TzsTtn8XOLJ4YOBFH8TElzKKI8Km2FdQkx4nJnlURlwQUFcUmB9ZZI= X-Received: by 2002:a17:907:96ab:b0:a51:b326:ed42 with SMTP id hd43-20020a17090796ab00b00a51b326ed42mr6820179ejc.54.1712634279822; Mon, 08 Apr 2024 20:44:39 -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> <08f67ddd-486e-4498-934d-c823be42dcab@case.edu> In-Reply-To: <08f67ddd-486e-4498-934d-c823be42dcab@case.edu> From: Zachary Santer Date: Mon, 8 Apr 2024 23:44:27 -0400 Message-ID: Subject: Re: Examples of concurrent coproc usage? To: chet.ramey@case.edu Cc: 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 11:07=E2=80=AFAM Chet Ramey wr= ote: > > Bash doesn't close the file descriptor in $fd. Since it's used with `exec= ', > it's under the user's control. > > The script here explicitly opens and closes the file descriptor, so it > can read until read returns failure. It doesn't really matter when the > process exits or whether the shell closes its ends of the pipe -- the > script has made a copy that it can use for its own purposes. > (And you need to use exec to close it when you're done.) Caught that shortly after sending the email. Yeah, I know. > You can do the same thing with a coproc. The question is whether or > not scripts should have to. If there's a way to exec fds to read from and write to the same background process without first using the coproc keyword or using FIFOs I'm all ears. To me, coproc fills that gap. I'd be fine with having to close the coproc fds in subshells myself. Heck, you still have to use exec to close at least the writing coproc fd in the parent process to get the coproc to exit, regardless. The fact that the current implementation allows the coproc fds to get into process substitutions is a little weird to me. A process substitution, in combination with exec, is kind of the one other way to communicate with background processes through fds without using FIFOs. I still have to close the coproc fds there myself, right now. Consider the following situation: I've got different kinds of background processes going on, and I've got fds exec'd from process substitutions, fds from coprocs, and fds exec'd from other things, and I need to keep them all out of the various background processes. Now I need different arrays of fds, so I can close all the fds that get into a background process forked with & without trying to close the coproc fds there; while still being able to close all the fds, including the coproc fds, in process substitutions. I'm curious what the reasoning was there.