Re: Proposed new feature for bash: unbuffered pipes

On 4/22/20 9:31 PM, Dale R. Worley wrote: > The crux of the problem, IMHO, is to look at it from the right angle: I'm not going to add this to bash. It's a bad idea to add a feature that will perpetually require a user to patch glibc (!), and that will never be added to any mainline glibc

Re: Proposed new feature for bash: unbuffered pipes

On April 22, 2020 6:32:07 PM wor...@alum.mit.edu (Dale R. Worley) wrote: The crux of the problem, IMHO, is to look at it from the right angle: Occasionally, the user desires that I/O through certain pipes should be unbuffered, that is, the stdio stream(s) that write into the pipe should be

Re: Proposed new feature for bash: unbuffered pipes

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

Re: Proposed new feature for bash: unbuffered pipes

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

Re: Proposed new feature for bash: unbuffered pipes

See stdbuf(1). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Re: Proposed new feature for bash: unbuffered pipes

The crux of the problem, IMHO, is to look at it from the right angle: Occasionally, the user desires that I/O through certain pipes should be unbuffered, that is, the stdio stream(s) that write into the pipe should be unbuffered, rather than the default block-buffered. These are situations where

Re: Proposed new feature for bash: unbuffered pipes, part 1: overview

Greg Wooledge writes: > 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

Re: Proposed new feature for bash: unbuffered pipes, part 1: overview

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

Proposed new feature for bash: unbuffered pipes, part 4: glibc.diff

diff --git a/libio/filedoalloc.c b/libio/filedoalloc.c index 412b8d5937..35044e3512 100644 --- a/libio/filedoalloc.c +++ b/libio/filedoalloc.c @@ -58,6 +58,7 @@ #include "libioP.h" #include #include +#include #include #include @@ -71,6 +72,17 @@ local_isatty (int fd) return res; }

Proposed new feature for bash: unbuffered pipes, part 3: bash.diff

diff --git a/command.h b/command.h index 3249516..ef611a4 100644 --- a/command.h +++ b/command.h @@ -186,6 +186,7 @@ typedef struct element { #define CMD_COPROC_SUBSHELL 0x1000 #define CMD_LASTPIPE 0x2000 #define CMD_STDPATH0x4000 /* use standard path for command lookup */

Proposed new feature for bash: unbuffered pipes, part 2: demo implementation

The baseline behavior is that this command, after 10 seconds, outputs 10 lines of output: $ bash -c 'for I in $( seq 10 ) ; do echo ABCDE ; sleep 1 ; done | grep A | cat' To build and run a demo of the "unbuffered pipes" feature: Create and cd to a scratch directory. Build a modified Bash: $

Proposed new feature for bash: unbuffered pipes, part 1: overview

It may seem intemperate to propose that a program with an 82-page manual "page" could benefit from yet another feature, but that is what this is doing: Bash's users would benefit from a feature that suppresses buffering of output sent to particular pipes (designated by the user). At the bottom