Jim Meyering wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>>> What about adding buffer control to all coretuils filters. >>>> Is that still a desired feature do you think? >>> I don't relish the idea of adding an option or feature >>> to each and every filter in coreutils. Especially >>> considering that this approach solves the problem -- >>> albeit with requirement on gcc and LD_PRELOAD. >>> Maybe we can relax that requirement... >> A general tool would be much better than adding options >> to all filters, hence why I originally asked to have this >> added to glibc. >> >> I wonder would it be useful to have a "Modified command invocation" >> command that set the LD_PRELOAD environment variable to point >> to a lib installed, and also set other environment variables >> to control the buffering depending on command line options. >> >> For example if we called the command stdbuf, then >> the following pipeline would be line buffered: >> >> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq >> >> size=0 => unbuffered >> size=1 => line buffered >> size>1 -> specific buffer size >> >> Also we could have aliases for stdin stdout, linebuffered, ... >> >> We still have the requirement on LD_PRELOAD, but >> that's not too bad I think? > > I like that. The "stdbuf" name sounds fine, too. > Though maybe use --size=-1 to indicate line buffering, > (or even a separate --line-buffered option), > rather than usurping --size=1. > > Sounds like you've just volunteered ;-)
Um Ok so :) Thinking a little more about it, the interface above is probably a little too general. I'm now thinking of 3 options: stdbuf -i -o -e The usual use case is: stdbuf -ol But you could also do: stdbuf -i4096 -o8192 We would warn about redundant combos like: stdbuf -il Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
