On Mon, 8 Feb 1999, Steven J. Dovich wrote:

> Bill Studenmund wrote:
> I have no argument with Bill's note, he simply collected the right
> thread of conversation to knock me off the fence I was sitting on.
> 
> It seems that using grep as a filtering process in a pipeline would
> be severely hampered by using this "binary file" interpretation.
> Consider the following case:
> 
> 	grep foo ./* | grep bar | ...
> 
> If we are concerned about not breaking scripts that use the assorted
> options to tar (the pax vs. GNU Tar debate), how about scripts using
> the above construct, or its moral equivalent...

I'm curius, how does that work with binary files? I mean what info do you
get out of it?

grep's ideas of what is a "line" is weird for a binary file. So I'm unsure
what good the second grep will be? And what is the end tool going to do
when it's fed machine code?

Just to reitterate: as I understand the proposal, you'll still be able to
grep "binary" files (as well as "text" files). You'll still get a message
when a match is found, I assume for each match. If it's a "text" file, you
see the whole line, just like now. If it's a "binary" file, you get a
match message.

So if all the ./* files are "text", you get what happens now. If some of
them are binary, you get a different behavior for the binary ones only. To
be honest, I don't understand the value of what you'd get now. :-)

(I'm repeating how I understand the proposal a lot so that I can make sure
we're all discussing the same thing. If things aren't as I understand
them, I'll change my opinion :-)

I think the message you'd get was mentioned early in the thread, but I'd
hope it includes both the filename with a colon (like normal multi-file
grep) and the matched string. So that if I grep for [aA]untie, I see which
files have auntie, which Auntie, and which occurences of both.

Take care,

Bill