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 780B01F44D for ; Fri, 19 Apr 2024 11:37:37 +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=cyJaI9WH; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 870373847700 for ; Fri, 19 Apr 2024 11:37:36 +0000 (GMT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 586603849AD9 for ; Fri, 19 Apr 2024 11:37:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 586603849AD9 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 586603849AD9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::52a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713526632; cv=none; b=WQIFb8tLhoGF6nTNA+pTFstK4Xxf16Jx2aufTDUO/syVjPEDdJixRbwLX6/Lw/WBWGc/IAa9SZeDdDvs5AmRQS6Q3HfR7ex21sROQL1PPdPTd2zYR1cVKI/qqGJugtr2naGwhfnI73SsIPqQoe66UHwHUqBtTQg0K60uA9fJjBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713526632; c=relaxed/simple; bh=K0m3hNbFwA8VY5Bu7M+u7KS58tuyPDow1fCdojnOR2s=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=viptCNQF4kDbU4DBf0jP0XbAo8e8OUy2JZ4JVc15Kb/79JOyFAxhjff72ynE1uUGFpmk1amCRQy6vv0bzHmKYpBHd6ErEdW0hNPD+lE5+DdQZFqQSYuHFe2USxVnlCUulQ0byE05seQO3JWnABMqqRIMyuCZgjOffHv9FKs5F0A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-571d6d1943fso475719a12.2 for ; Fri, 19 Apr 2024 04:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713526629; x=1714131429; 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=4l9MtSn662oc0pXpMCShuiwgoPavvbWAoDIkwhEdlus=; b=cyJaI9WHUoYZXHdpDqK5uJ62qXq+pRDX6qsvtw3lnXcrnr6T+0x7wMmcD6GIwPj8uS Zv+oev0R0J3vKjQGfASaOQT8WrEHrR55WPjstUlIYSry1U8acNXWjVOpyqKppc+m49ic Wgz6pMAMuQPFqjRFcHNLwoRswuhOJMuhLVr9kW6LlIjzGDu4qm6zjtJVNxupSRHmwYch FPreiPMl/XzjatPQAt2b1/EulT1Yk1xOlU4vnmuGug0NXIWjpGJhOTMHelYqfselLs2J WKiUVABC6QS3ogsvh6MikotE7JSzkjxqUO3IRngRMibjyJm2IEZPnkEQ9ZFzhwrsrZ81 xSsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713526629; x=1714131429; 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=4l9MtSn662oc0pXpMCShuiwgoPavvbWAoDIkwhEdlus=; b=qd32oxO1xWeApLli1kVrrRs0Cgb2kLLAdVSxjuQU0Cy1xoy9XuLYqg4dDQWb/thIM9 DW64gMyY14jj4FPviQtT3lPlL50SScWHxWuvoypPoDtKE2PHs6Ybvn1MU1ahwYDVqE1r 6l5geG1m2GN+nZQNFufItCRb8YTOrZah+TkQGpq6DitH7Yttet6PHehXS//uD1MXHi40 MDZjgS0C2q/vB1WYFLkRDVXwVoLi3E5FrYJKVnuZix5Pl+9+7YtW0alpxeBvV1tasmKi VHWkD5AIBy8vxzetsLFzNqAf3Kwa2CZLw4MjJatVYI6gZ4JwLi3gQVPBZ7YB7XFbjQSJ 74Iw== X-Forwarded-Encrypted: i=1; AJvYcCWANnReKXbowkfqHtWSn894Qf6byVWqgWSZ2U0vXT4wD+DyPPsZQGWJVwVZXHNExwjJ4qQMCkHGZjs3YYPp+M4A1oe2mljWvwfc X-Gm-Message-State: AOJu0YwPWGGxOz4rIwejwG3mE18d33Kj5W5Jxqp3CWXIru8rT5y6maWY LTB7z457FLX7+rSrvKxeYKV43ieX0/sS/4aFz98OnpVbuvr2baQczEULiB91224E/uWaXM7oNxe P6PBr6uUgVm+BQHnN8UtxjQWDeRU= X-Google-Smtp-Source: AGHT+IEWR3iqVQAYUd96He5mtdimUeOkRQYQaeAkPeej0q8gCQggf1r2+6pdsYB1RBuG1MZz7Mp1XqFhn8Xo+V/IJRY= X-Received: by 2002:a17:906:7708:b0:a51:969e:ba0 with SMTP id q8-20020a170906770800b00a51969e0ba0mr1165511ejm.44.1713526628842; Fri, 19 Apr 2024 04:37:08 -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> <8d26e5046cc8bf49490e4aa3f6c00b09@kylheku.com> In-Reply-To: From: Zachary Santer Date: Fri, 19 Apr 2024 07:36:57 -0400 Message-ID: Subject: Re: Modify buffering of standard streams via environment variables (not LD_PRELOAD)? To: =?UTF-8?Q?P=C3=A1draig_Brady?= Cc: Carl Edquist , Kaz Kylheku , libc-alpha@sourceware.org, coreutils@gnu.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 Fri, Apr 19, 2024 at 5:32=E2=80=AFAM P=C3=A1draig Brady wrote: > > env variables are what I proposed 18 years ago now: > https://sourceware.org/bugzilla/show_bug.cgi?id=3D2457 And the "resistance to that" from the Red Hat people 24 years ago is listed on a website that doesn't exist anymore. If I'm to argue with a guy from 18 years ago... Ulrich Drepper wrote: > Hell, no. Programs expect a certain buffer mode and perhaps would work > unexpectedly if this changes. By setting a mode to unbuffered, for insta= nce, > you can easily DoS a system. I can think about enough other reasons why = this is > a terrible idea. Programs explicitly must request a buffering scheme so = that it > matches the way the program uses the stream. If buffering were set according to the env vars before the program configures buffers on its end, if it chooses to, then the env vars have no effect. This is how the stdbuf util works, right now. Would programs that expect a certain buffer mode not set that mode explicitly themselves? Are you allowing untrusted users to set env vars for important daemons or something? How is this a valid concern? This is specific to the standard streams, 0-2. Buffering of stdout and stderr is already configured dynamically by libc. If it's going to a terminal, it's line-buffered. If it's not, it's fully buffered.