On Sat, 6 Feb 1999 23:26:14 +0100 (MET)  Christoph Badura wrote:

> simonb@telstra.com.au (Simon Burge) writes:
> >I don't understand the objection here - grep _not_ printing binary data
> >was the reason I upgraded to the lastest version on my Ultrix/Solaris
> >work machines.  I can't think of a _single_ case where the binary output
> >would be useful.  You can always get the "normal" output with the new -a
> >option.
> 
> So tell me one thing.   Since Unix doesn't have the concept of binary files
> (or rather -- since it treats all files as an opaque stream of binary octets
> -- no concept of non-binary files) how can grep possibly tell that a given
> file isn't a binary file?

The test that grep uses to decide if a file is binary is to look for a
NUL in the first 32k of the file (or the total file if it's less that
32k).  Note that I'm not an international language specifist by _any_
stretch of the imagination, but this would seem like a valid test.

> Will that depend on some obscure environment variable?
> Will grep decide behind my back, that I don't really want to grep
> those Japanese text files I'm telling it to look for string in?
> 
> Note also, that I grep object files regularly enough that having
> to remember that I now need -a for what has "just worked" for the last 15
> year would be utterly annoying to me.

Completely seriously - of what use can this be?  When I've accidently
grep'd some sort of object file, more often than not my xterm needs to
have a full reset from the ctrl-middle-btn menu because text is now
invisible or something else.  Pagers like more and less handle this
better - if this is what you do, would a compromise like a check of
isatty(STDOUT_FILENO) do?

> Perhaps you should work more with Windows to find out for yourself how
> annoying programs are which think they know better then you what is good for
> you.  (That's where the reference comes from.)

No thanks, I value some semblance of sanity :)

Simon.