Subject: Re: Suggestion: keep binary data out of /etc
To: Steven J. Dovich <email@example.com>
From: Bill Studenmund <skippy@macro.Stanford.EDU>
Date: 02/09/1999 09:56:10
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
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.