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=-1.0 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,T_SCC_BODY_TEXT_LINE 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 52AA71F44D for ; Mon, 18 Mar 2024 00:13:06 +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=Nwywo1Ye; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7E3F8385840A for ; Mon, 18 Mar 2024 00:13:05 +0000 (GMT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 43EDA3858D37 for ; Mon, 18 Mar 2024 00:12:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 43EDA3858D37 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 43EDA3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::635 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710720765; cv=none; b=kHB2cIgo6VWHDi0F98lER+3rqEmfOxnZBZZDSCXM6FlLU1jszK5l9418Idhq7u+ZUe1nEYA9cZEheeA/FbUAZ17qU/kkax59lGVhd8bq/PswHkpL0AxR8TUoPGxFgpZgTvqMSi79rU55BxtyaiT+w0/JFTYhB046j+4JnjGvCCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710720765; c=relaxed/simple; bh=S/wU32RCf0sJmM1vs391DkF7VtXpUJhZVlKJqsdMiVY=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=wdwD5HJo5pzt2qImae0nEK2ahBxiqINEejXsqiPZRnz8Mw7I13lyzEecFz13oDe7CyHJieNE4LYg9TVSfg4keXr1dzpesfFW53rH32D+miO1aFv0gy9qaz27G7b/Ke4ciOmjp99sC6o7zi+7YcCyAoOVBpW0rrXcNFEJgFDD+w4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a44f2d894b7so426296466b.1 for ; Sun, 17 Mar 2024 17:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710720762; x=1711325562; 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=E2RwDV/BGeFUgFp664TCTt3SMPnVPwdqEl8D2JnMRbg=; b=Nwywo1YeqA3IKLPA0ZCeBxesssAqXuW6YzbafQZBHw01F8hDMrEvwseyKt+yBNiinr EljJnXs0SFW7TzNIruBJq2mrsKTjXWV9/uggWkUFcOgyfoFW+1Ki3xdj/NTS3Kbr3nHq dEI9IfJ0HY0x/j0+9/4K2vhUdVRKFdKH+RPAI7fJZGPUZJBj783mnLCsCUM1/WB1B39z gipC3RWPoySaP389hymhHsMuyvAJpK4hxo6Rt4nGc4GdmRGGKVIvKuII9XZpAMh5Q0B1 xPHt9PTG7p8l8nFOLGt5fgqv0Zzqhqi9easuqNjH1GtShFpSW6brc/K8o66J7xgJtn+s SJVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710720762; x=1711325562; 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=E2RwDV/BGeFUgFp664TCTt3SMPnVPwdqEl8D2JnMRbg=; b=U1QsQtawZIoUUJsSAw+kEOoNyeLP78g2QAvBPbM06Vdz3+JiL4bcp8n1pp/u7ttcYu SLbUTpC2Ub9d11NHrswu56oD1wrcu8jGZaDTkkj+mbz6g1NwiUdjKegxM/fYKpfq0ZdF usou0AHRjHNzgNVd7nCSPb53/rFdv9Qh7PYVomhMZ7tnoJqO2pOt2pO323YZL7OKH933 Ri2mm2e2cJnFzDXKC/nn+3nj8jjWQ+nAFYjCnzvKA0wjMzBXFLyAnrdX9PNk9qwTC/jG 5pBfwgaRIcM7qLYWUjywda/OYgm+fjQ78i4V3fvGpPfHduC4ccmoMSu6izNys4c7ZtP6 CFBA== X-Gm-Message-State: AOJu0YxSjBoRJePeLttil1Hzqdz9NuTQCg/zFrheP/S842B+M/eOkOxa +KKU4BhOyYXj5Ouid4aunxcK0oR0Xrj69aR8KPgWXfXfiVEA754WXiSczUEYFKPHX3KH82naesv E+LBdDsV3KH+p07Gam4cmVnvq4eY= X-Google-Smtp-Source: AGHT+IF/H5Njb6ayXPNpRtfX1Fp9wq/wOC2vlC374gJxi7HL3GS+xuTC8nEL4kUB30cUsyKj5QlqLSIYpCj84EpLTdI= X-Received: by 2002:a17:906:bfe6:b0:a46:4c8e:1afd with SMTP id vr6-20020a170906bfe600b00a464c8e1afdmr7777363ejb.6.1710720761810; Sun, 17 Mar 2024 17:12:41 -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> In-Reply-To: From: Zachary Santer Date: Sun, 17 Mar 2024 20:12:29 -0400 Message-ID: Subject: Re: RFE: enable buffering on null-terminated data To: Carl Edquist Cc: libc-alpha@sourceware.org, coreutils@gnu.org, p@draigbrady.com 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 Thu, Mar 14, 2024 at 11:14=E2=80=AFAM Carl Edquist = wrote: > Where things get sloppy is if you add some stuff in a pipeline after your > build script, which results in things getting block-buffered along the > way: > > $ ./build.sh | sed s/what/ever/ | tee build.log > > And there you will definitely see a difference. Sadly, the man page for stdbuf specifically calls out tee as being unaffected by stdbuf, because it adjusts the buffering of its standard streams itself. The script I mentioned pipes everything through tee, and I don't think I'm willing to refactor it not to. Ah well. > Oh, I imagine "undefined operation" means something more like > "unspecified" here. stdbuf(1) uses setbuf(3), so the behavior you'll get > should be whatever the setbuf(3) from the libc on your system does. > > I think all this means is that the C/POSIX standards are a bit loose abou= t > what is required of setbuf(3) when a buffer size is specified, and there > is room in the standard for it to be interpreted as only a hint. > Works for me (on glibc-2.23) Thanks for setting me straight here. > What may not be obvious is that the shell does not need to get involved > with writing input for a coprocess or reading its output - the shell can > start other (very fast) programs with input/output redirected to/from the > coprocess pipes to do that processing. Gosh, I'd like to see an example of that, too. > My point though earlier was that a null-terminated record buffering mode, > as useful as it sounds on the surface (for null-terminated paths), may > actually be something _nobody_ has ever actually needed for an actual (no= t > contrived) workflow. I considered how it seemed like something people could need years ago and only thought to email into email lists about it last weekend. Maybe there are all sorts of people out there who have been using 'stdbuf --output=3D0' on null-terminated data for years and never thought to raise the issue. I know that's not a very strong argument, though.