Re: grep problems

[Alain Magloire]

> 
> 
> grep (GNU grep) 2.4.2... Not necessarily bugs, but I think it would be a
> good idea to implement it:
> 
> 1) -A, -B and -num options have undesired effects in -v mode:
> 
>   $ echo -e 'one\ntwo\nthree\nfour\nfive' | grep -1 three
>   two
>   three
>   four
> 
>   This is correct. "Three" and one line before and after is picked.
>   Now, -v option is supposed to reverse 'grep' behavior. Thus,
>   we should get everything except lines that normal 'grep' returned:
> 
>   $ echo -e 'one\ntwo\nthree\nfour\nfive' | grep -v -1 three
>   one
>   two
>   three
>   four
>   five
> 
>   Wouldn't it be more reasonable, suitable and useful for the last command
>   to return "one, five"? In my opinion, as -v mode should be an opposite
>   of normal mode - so grep -v something always return everything that
>   'grep something' didn't return and nothing more... -A, -B and -nnn options 
>   should refer to number of lines skipped along with the matching line.
> 
>   Of course, you might disagree, but then, is there any chance to have
>   appropriate option to modify default behavior and make -A and -B
>   work the way I described?

Unlikely, unless you submit a patch to the maintainer(assuming the maitainer
is favorable to it).

> 
> 2) Buffering. Very often, grep is used this way:
>  
>    ./somecommand | grep something | othercommands
> 
>   ...or this way:
> 
>    ./somecommand | grep something | grep -v something
> 
>   In both cases, the second command (grep something) is having stdout
>   redirected to something that is not a terminal. As a result, libc
>   deploys rather heavy buffering, and output is not continous. For
>   example, if somecommand generates one line of output every second,
>   this sequence will cause 'othercommands' or 'grep -v something'
>   to get 10 lines of output every 10 seconds, and nothing in between.
>   This is very often something not desirable, especially if time
>   intervals for 'somecommand' output are irregular and longer than one
>   second. The most obvious example would be:
> 
>   tail -f /var/log/messages | grep -i pop3 | grep -vF '123.123.123.123'
> 
>   You won't see continous output in real-time.
> 
>   Some commands that are supposed to be used in such sequences (e.g.
>   tcpdump), implement an option to perform fflush(stdout) after
>   every line (for tcpdump, this would be -l option). This enables
>   the user to arrange constant flow of text information in such
>   command sequence. Many others simply fflush(stdout) after 
>   every line, no matter what (e.g. tail -f).
> 
>   Do you believe it makes sense to implement similar option for grep?
>   It certainly wouldn't hurt, and might be very useful for many
>   people.

The beta versions(starting from 2.5e) comes with, extrait from grep.texi:

@item --line-buffered
@opindex --line-buffered
@cindex line buffering
Set the line buffering policy, this can be a performance penality.