Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Daniel Colascione Newsgroups: gnu.bash.bug Subject: Re: Proposed new feature for bash: unbuffered pipes Date: Thu, 23 Apr 2020 17:15:52 -0700 Lines: 23 Approved: bug-bash@gnu.org Message-ID: References: <87blnhvkki.fsf@hobgoblin.ariadne.com> <7f4f4dcb-a5be-9a5b-aa51-fddf285dbbf2@dancol.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1587687374 28589 209.51.188.17 (24 Apr 2020 00:16:14 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: "Dale R. Worley" , Andreas Schwab Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pzXsDEzuAMgISeBF8qwqdZTrDVIkvELOGE9O8OYYPbA=; b=ekUsHtAdnCZQgz8Wd3iUARdEt5 WCzGV0Iuqq7DsG/EferkaMPbQ9pW55i18Cu4wnUiZ54hHC65qHTUS3YAfIQgusNwbjeN/wzCOoLsW 9P6yzxeWMf+txNpceN261BuPsuVY1vLyKgy0XnFXNdl9SMozuc1vKCW8a58Y6yea7s1Zn5J4UBwaX qZWeclx+ia6Xy0rb1r/XjQ5KuZD4LAz+78HG85PBkmIKML1Yk3BxbdoJAfoJpkPY19dkZCkj7mhLj 4ge0HVwE7PsfasRGWimtN4FVC30EA64FNn9X2srWCbuE7BnB41VLq9hhbwOsky3XNY6GZcA4oSZkk yEZCp2nw==; User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <87blnhvkki.fsf@hobgoblin.ariadne.com> Content-Language: en-US Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <7f4f4dcb-a5be-9a5b-aa51-fddf285dbbf2@dancol.org> X-Mailman-Original-References: <87blnhvkki.fsf@hobgoblin.ariadne.com> Xref: csiph.com gnu.bash.bug:16233 On 4/23/20 4:39 PM, Dale R. Worley wrote: > Andreas Schwab writes: >> See stdbuf(1). > > The limitation(s) of stdbuf are: It can only be applied to the standard > I/O streams. It doesn't affect statically-linked executables. It only > applies to a single executable, so if the command is a shell function or > script, or creates subprocesses, it doesn't affect them. If you want to define an environment variable for affecting stdout buffering, you can. (Good luck getting any libc to implement the support you're imagining: libc authors are *very* conservative about everything.) But whether or not you have this environment variable, you don't need special bash syntax to set it: you can just prefix the command you want with an environment variable assignment. I don't think the need you're discussing is widespread enough to warrant further complicating shell syntax. A much simpler option might be just convincing libc people to make line-buffering the default whether isatty or not. Machines are very fast these days, and any program that _knows_ it's emitting non-line-oriented data can opt into full buffering.