Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Greg Wooledge Newsgroups: gnu.bash.bug Subject: Re: Proposed new feature for bash: unbuffered pipes, part 1: overview Date: Wed, 22 Apr 2020 07:36:06 -0400 Lines: 22 Approved: bug-bash@gnu.org Message-ID: References: <87lfmowe0e.fsf@hobgoblin.ariadne.com> <20200422113606.GD845@eeg.ccf.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1587555399 4627 209.51.188.17 (22 Apr 2020 11:36:39 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org Mail-Followup-To: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <87lfmowe0e.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: none client-ip=139.137.100.1; envelope-from=wooledg@eeg.ccf.org; helo=mail.eeg.ccf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/22 07:36:07 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 139.137.100.1 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: <20200422113606.GD845@eeg.ccf.org> X-Mailman-Original-References: <87lfmowe0e.fsf@hobgoblin.ariadne.com> Xref: csiph.com gnu.bash.bug:16226 On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote: > The "unbuffered pipe" symbol ">|>" causes Bash to set in the > environment of the "grep" process a variable "STDOUT_UNBUFFERED" with > a value that contains the dev and ino values for the pipe which the > "grep" process sees as fd 1. Which libc implements this? > References > > 14 Sep 1999 > https://marc.info/?l=glibc-bug&m=98313957306295&w=4 > "[REMINDER] stdio buffer flushing control environment variable" The next message in the thread is from Ulrich Drepper, saying: I will not implement this since it's completely up to the application to do this. One knows in advance when this is necessary. If there is a problem with the current code to select when line-buffering is used (we use as everybody else isatty) then one can talk about this. I think it is correct, though.