On 23/11/06, Matthew Hannigan <[EMAIL PROTECTED]> wrote:
On Thu, Nov 23, 2006 at 05:10:14PM +1100, Penedo wrote:
> On 23/11/06, Matthew Hannigan <[EMAIL PROTECTED]> wrote:
> >You don't get the output in as timely a fashion;
> >it comes with spurts as the buffer is filled up
> >then written out.
>
> What buffer? tail's manual doesn't mention anything about buffers but
grep's buffer, the normal stdio buffer I guess
That's what I guessed that you were referring to (and what I'd suspect
too), but it seems to work for me even without the --line-buffered
switch.
> --line-buffering on grep. So far I thing this confirms my theory.
Weird.
With --line-buffered on the first grep I get it continuous.
If only the second grep is --line-buffered, then it goes spurty again.
That points to the first grep buffering by default, to me.
You are right - the second grep won't get any input until the first
one flushes its buffer.
What kernel and libc do you use? This buffering is usually handled by stdio.
> Another experiment - slow down the data writing into "crap" and see
> whether you get individual lines of 5-6 bytes each - this again should
> prove the "buffer theory" wrong, IMHO.
It's possible it's a difference in kernels/shells/something else,
but that's certainly unexpected.
What's your kernel/libc/grep/tail version (the shell is out of the
pipeline once it's setup)?
Mine is Debian Etch, i.e.:
linux 2.6.17
GNU tail 5.97
GNU grep 2.5.1
I didn't even know about tail's -s option. That's what I get
for spending too much time in a non-GNU wilderness.
Me neither - I RTFM'ed while taking part in this thread.
I still think there's a case for a 'less' like tool, or
less itself to do some filtering, modifiable on the fly.
I'm sure there's some perl module/program to do it.
Almost "by definition". See perl's "seek" documentation
(http://perldoc.perl.org/functions/seek.html)
--P
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
