Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16226
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Proposed new feature for bash: unbuffered pipes, part 1: overview |
| Date | 2020-04-22 07:36 -0400 |
| Message-ID | <mailman.940.1587555398.3066.bug-bash@gnu.org> (permalink) |
| References | <87lfmowe0e.fsf@hobgoblin.ariadne.com> <20200422113606.GD845@eeg.ccf.org> |
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.
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Proposed new feature for bash: unbuffered pipes, part 1: overview Greg Wooledge <wooledg@eeg.ccf.org> - 2020-04-22 07:36 -0400
csiph-web