Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Fri, Nov 12, 1999 at 20:45:10 -0800, Paul Eggert wrote:
Date: Fri, 12 Nov 1999 17:23:21 -0800
From: "David O'Brien" [EMAIL PROTECTED]
I assume "--ignore-binary" or "--ignore-binary-files" would be the GNU
longopt.
Another possibility would be to follow the example of the existing
--directories=ACTION option, e.g. something like this:
--binary-files=ACTION how to handle binary files
ACTION is 'read', 'skip', or 'summarize' (default)
-I equivalent to --binary-files=skip
-a, --text equivalent to --binary-files=read
Paul, could you please consider applying the following patch (it is against
virgin grep-2.4 sources). Could you please also let me know when the Alpha
with this feature will be made available, so I could import it into FreeBSD.
Or maybe tell me an address of appropriate "announce" mailing list...
Thanks,
--
Ruslan Ermilov Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
--- grep.c.orig Sat Nov 13 18:31:55 1999
+++ grep.c Tue Jan 4 14:11:09 2000
@@ -60,7 +60,7 @@
/* Short options. */
static char const short_options[] =
-"0123456789A:B:C::EFGHUVX:abcd:e:f:hiLlnqrsuvwxyZz";
+"0123456789A:B:C::EFGHIUVX:Y:abcd:e:f:hiLlnqrsuvwxyZz";
/* Long options equivalences. */
static struct option long_options[] =
@@ -68,6 +68,7 @@
{"after-context", required_argument, NULL, 'A'},
{"basic-regexp", no_argument, NULL, 'G'},
{"before-context", required_argument, NULL, 'B'},
+ {"binary-files", required_argument, NULL, 'Y'},
{"byte-offset", no_argument, NULL, 'b'},
{"context", optional_argument, NULL, 'C'},
{"count", no_argument, NULL, 'c'},
@@ -120,6 +121,14 @@
SKIP_DIRECTORIES
} directories;
+/* How to handle binary files. */
+static enum
+ {
+SUMMARIZE_BINARIES,
+READ_BINARIES,
+SKIP_BINARIES
+ } binaries;
+
static int ck_atoi PARAMS ((char const *, int *));
static void usage PARAMS ((int)) __attribute__((noreturn));
static void error PARAMS ((const char *, int));
@@ -476,7 +485,6 @@
}
/* Flags controlling the style of output. */
-static int always_text;/* Assume the input is always text. */
static int filename_mask; /* If zero, output nulls after filenames. */
static int out_quiet; /* Suppress all normal output. */
static int out_invert; /* Print nonmatching stuff. */
@@ -732,11 +740,14 @@
return nlines;
}
- not_text = (! (always_text | out_quiet)
+ not_text = (binaries != READ_BINARIES
memchr (bufbeg, eol ? '\0' : '\200', buflim - bufbeg));
done_on_match += not_text;
out_quiet += not_text;
+ if (not_text binaries == SKIP_BINARIES)
+goto finish_grep;
+
for (;;)
{
lastnl = bufbeg;
@@ -993,10 +1004,13 @@
-H, --with-filename print the filename for each match\n\
-h, --no-filename suppress the prefixing filename on output\n\
-q, --quiet, --silent suppress all normal output\n\
- -a, --textdo not suppress binary output\n\
-d, --directories=ACTION how to handle directories\n\
ACTION is 'read', 'recurse', or 'skip'.\n\
-r, --recursive equivalent to --directories=recurse.\n\
+ -Y, --binary-files=ACTION how to handle binary files\n\
+ACTION is 'summarize' (default), 'read', or 'skip'.
+ -a, --textequivalent to --binary-files=read\n\
+ -Iequivalent to --binary-files=skip\n\
-L, --files-without-match only print FILE names containing no match\n\
-l, --files-with-matches only print FILE names containing matches\n\
-c, --count only print a count of matching lines per FILE\n\
@@ -1276,7 +1290,7 @@
setmatcher (optarg);
break;
case 'a':
- always_text = 1;
+ binaries = READ_BINARIES;
break;
case 'b':
out_byte = 1;
@@ -1326,6 +1340,9 @@
case 'h':
no_filenames = 1;
break;
+ case 'I':
+ binaries = SKIP_BINARIES;
+ break;
case 'i':
case 'y':/* For old-timers . . . */
match_icase = 1;
@@ -1363,6 +1380,16 @@
break;
case 'x':
match_lines = 1;
+ break;
+ case 'Y':
+ if (strcmp (optarg, "summarize") == 0)
+ binaries = SUMMARIZE_BINARIES;
+ else if (strcmp (optarg, "read") == 0)
+ binaries = READ_BINARIES;
+ else if (strcmp (optarg, "skip") == 0)
+ binaries = SKIP_BINARIES;
+ else
+ fatal (_("unknown binary-files method"), 0);
break;
case 'Z':
filename_mask = 0;
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
--n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii On Fri, Nov 12, 1999 at 20:45:10 -0800, Paul Eggert wrote: Date: Fri, 12 Nov 1999 17:23:21 -0800 From: "David O'Brien" [EMAIL PROTECTED] I assume "--ignore-binary" or "--ignore-binary-files" would be the GNU longopt. Another possibility would be to follow the example of the existing --directories=ACTION option, e.g. something like this: --binary-files=ACTION how to handle binary files ACTION is 'read', 'skip', or 'summarize' (default) -I equivalent to --binary-files=skip -a, --text equivalent to --binary-files=read Paul, could you please consider applying the following patch (it is against virgin grep-2.4 sources). Could you please also let me know when the Alpha with this feature will be made available, so I could import it into FreeBSD. Or maybe tell me an address of appropriate "announce" mailing list... Bonjour I'm presently busy, with some other problems. Will commit the patch later. The alphas/betas are usually on alpha.gnu.org/gnu/grep. Do you wish to be on the beta list, to be notify ? There is no ETA for grep, the plan is to let the 2.4 propagate and wait for the reports, 2.4.1 will be release to correct any major problems, David's patch will be part of it. BTW, David can you please provide a ChangeLog entry and thanks for the patch. -- au revoir, alain Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Thanks for implementing the result of our earlier discussion. I
documented what you wrote, and as a result I have the following
suggestions for further improvements:
* The assignment to not_text should depend on out_quiet
if no --binary-files option is given.
* The operands of --binary-files are confusing. E.g. --binary-files=read
implies that --binary-options=summarize and --binary-options=skip
don't read binary files, which isn't true. And --binary-options=skip
implies that binary files aren't mentioned on output, which also isn't true
(a counterexample is --files-without-match --binary-options=skip).
I propose that the operands be renamed from (read, skip, summarize)
to (text, without-match, binary).
* There's no need for a short equivalent to the --binary-files option.
* Is the -I option really needed? Can't users just use
--binary-files=without-match instead? I have the impression that
this option won't be typed interactively much.
Could you please try the patch enclosed below instead?
It implements all the above suggestions.
2000-01-04 Paul Eggert [EMAIL PROTECTED]
Add --binary-files option.
* NEWS, doc/grep.1, doc/grep.texi: Document it.
* src/grep.c (BINARY_FILES_OPTION): New constant.
(long_options, grep, usage, main): New --binary-files option.
(binary_files): New var.
* src/system.h (TYPE_SIGNED, TYPE_MINIMUM, TYPE_MAXIMUM, CHAR_MAX):
New macros.
(INT_MAX, UCHAR_MAX): Define in terms of TYPE_MAXIMUM.
===
RCS file: doc/grep.1,v
retrieving revision 2.4
retrieving revision 2.4.0.1
diff -pu -r2.4 -r2.4.0.1
--- doc/grep.1 1999/10/12 20:41:22 2.4
+++ doc/grep.1 2000/01/05 06:35:00 2.4.0.1
@@ -28,6 +28,7 @@ grep, egrep, fgrep \- print lines matchi
.IR FILE ]
.RB [ \-d
.IR ACTION ]
+.RB [ \-\^\-binary-files=\fITYPE\fP ]
.RB [ \-\^\-directories=\fIACTION\fP ]
.RB [ \-\^\-extended-regexp ]
.RB [ \-\^\-fixed-strings ]
@@ -143,6 +144,41 @@ Print the version number of
to standard error. This version number should
be included in all bug reports (see below).
.TP
+.BI \-\^\-binary-files= TYPE
+If the first few bytes of a file indicate that the file contains binary
+data, assume that the file is of type
+.IR TYPE .
+By default,
+.I TYPE
+is
+.BR binary ,
+and
+.B grep
+normally outputs either
+a one-line message saying that a binary file matches, or no message if
+there is no match.
+If
+.I TYPE
+is
+.BR without-match ,
+.B grep
+assumes that a binary file does not match.
+If
+.I TYPE
+is
+.BR text ,
+.B grep
+processes a binary file as if it were text; this is equivalent to the
+.B \-a
+or
+.B \-\^\-text
+option.
+.I Warning:
+.B "grep \-\^\-binary-files=text"
+might output binary garbage,
+which can have nasty side effects if the output is a terminal and if the
+terminal driver interprets some of it as commands.
+.TP
.BR \-b ", " \-\^\-byte-offset
Print the byte offset within the input file before
each line of output.
@@ -257,15 +293,9 @@ and
and should redirect output to /dev/null instead.
.TP
.BR \-a ", " \-\^\-text
-Do not suppress output lines that contain binary data.
-Normally, if the first few bytes of a file indicate that
-the file contains binary data,
-.B grep
-outputs only a message saying that the file matches the pattern.
-This option causes
-.B grep
-to act as if the file is a text file,
-even if it would otherwise be treated as binary.
+Process a binary file as if it were text; this is equivalent to the
+.B \-\^\-binary-files=text
+option.
.TP
.BR \-v ", " \-\^\-invert-match
Invert the sense of matching, to select non-matching lines.
@@ -323,9 +353,9 @@ system call to read input, instead of
the default
.BR read (2)
system call. In some situations,
-.B -\^-mmap
+.B \-\^\-mmap
yields better performance. However,
-.B -\^-mmap
+.B \-\^\-mmap
can cause undefined behavior (including core dumps)
if an input file shrinks while
.B grep
===
RCS file: doc/grep.texi,v
retrieving revision 2.4
retrieving revision 2.4.0.1
diff -pu -r2.4 -r2.4.0.1
--- doc/grep.texi 1999/11/13 21:20:24 2.4
+++ doc/grep.texi 2000/01/05 06:35:00 2.4.0.1
@@ -275,6 +275,21 @@ This version number should be included i
Print a usage message briefly summarizing these command-line options
and the bug-reporting address, then exit.
+@itemx --binary-files=@var{type}
+@opindex --binary-files
+@cindex binary files
+If the first few bytes of a file indicate that the file contains binary
+data, assume that the file is of type @var{type}. By default,
+@var{type} is @samp{binary}, and @command{grep} normally outputs either
+a one-line message saying that a binary file matches, or no message if
+there is no match. If @var{type} is @samp{without-match},
+@command{grep} assumes that a binary file does not match. If @var{type}
+is
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Fri, Nov 12, 1999 at 12:11:22AM -0800, Paul Eggert wrote: Date: Thu, 11 Nov 1999 23:39:10 -0800 From: "David O'Brien" [EMAIL PROTECTED] Would it be possible to either ignore binary files when "-l" is in affect. OR to add an ignore binary file flag (like FreeBSD has in 2.x and 3.x)? The latter sounds reasonable, though it'd have to be spelled differently from -a since -a is now taken. Perhaps --skip-binary-files, by analogy with the existing --directories=skip option? The BSD's favor one letter options. At the time -a was not used for anything. Is there a letter we could use today? I used -a almost all the time, so typing "--skip-binary-files" would have been unacceptable. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Thu, Nov 11, 1999 at 09:13:54PM -0500, Alain Magloire wrote: Of course, you can. But I will join my voice to Paul and ask you not to. This behaviour was a long standing request/grip where for example one would do grep pattern * and have the terminal going bananas, if pattern was detected in binary What I was proposing to change was that binary files were ignored when "-l" was in affect. I was also implying that binary files should be silently ignored unless one uses the 2.3 "-a" flag. I don't follow your logic for '-l'. whether it is grep-2.0 or grep-2.3 They all show the filename containing a matching pattern. FreeBSD's previous grep had a "-a" flag to ignore binary files. Thus I'm trying to find a replacement for the old ``grep -al'' usage. In the coming 2.4, if this is such problem for you, there is en environ variable, that will restore the 2.0 behaviour(everything is text) Not quite what I'm looking for. I want a silent ignore of binary files. I think it should take an option to not ignore binary files. Add 2.3's "-a" if you *really* want full greping of binary files. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Date: Fri, 12 Nov 1999 09:08:24 -0800 From: "David O'Brien" [EMAIL PROTECTED] I want a silent ignore of binary files. It'd be reasonable to add an option to do this, after the feature freeze is over and 2.4 comes out. I think it should take an option to not ignore binary files. I disagree. If I type `grep pattern file' and get no output, then I should be able to conclude that there are no instances of `pattern' in `file'. But under your proposal, I wouldn't be able to conclude that: all I would know is that either the file contained no instances, or the file was binary. This is confusing and is less useful in practice than grep 2.3's behavior. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Fri, Nov 12, 1999 at 03:39:43PM -0800, Paul Eggert wrote: Date: Fri, 12 Nov 1999 09:08:24 -0800 From: "David O'Brien" [EMAIL PROTECTED] I want a silent ignore of binary files. It'd be reasonable to add an option to do this, after the feature freeze is over and 2.4 comes out. Cool! :-) Would you able to reserve the option's letter and GNU-style long name now? I'd like to add this feature to GNU Grep 2.3 in FreeBSD. Is there an alpha of 2.4 available anywhere? I wouldn't mind adding the environmental vars support to our 2.3 also. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Bonjour M. David O'Brien FreeBSD's previous grep had a "-a" flag to ignore binary files. Thus I'm trying to find a replacement for the old ``grep -al'' usage. In the coming 2.4, if this is such problem for you, there is en environ variable, that will restore the 2.0 behaviour(everything is text) Not quite what I'm looking for. I want a silent ignore of binary files. I think it should take an option to not ignore binary files. Add 2.3's "-a" if you *really* want full greping of binary files. Thanks, for the clarifications. It is "dommage" (too bad ?) that the changes were not sent back to gnu. -- au revoir, alain Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Bonjour M. David O'Brien On Fri, Nov 12, 1999 at 03:39:43PM -0800, Paul Eggert wrote: Date: Fri, 12 Nov 1999 09:08:24 -0800 From: "David O'Brien" [EMAIL PROTECTED] I want a silent ignore of binary files. It'd be reasonable to add an option to do this, after the feature freeze is over and 2.4 comes out. Cool! :-) Would you able to reserve the option's letter and GNU-style long name now? I'd like to add this feature to GNU Grep 2.3 in FreeBSD. -a, --text is already taken. Option letter is something rather scarce for GNU grep, but I think there's some left ;-) Is there an alpha of 2.4 available anywhere? I wouldn't mind adding the environmental vars support to our 2.3 also. grep-2.3h beta released (Freeze). wget ftp://alpha.gnu.org/gnu/grep/grep-2.3h.tar.gz wget ftp://mccoy.ee.mcgill.ca/pub/alain/grep/beta/2.3/grep-2.3h.tar.gz -- au revoir, alain Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Fri, Nov 12, 1999 at 08:09:24PM -0500, Alain Magloire wrote: Cool! :-) Would you able to reserve the option's letter and GNU-style long name now? I'd like to add this feature to GNU Grep 2.3 in FreeBSD. -a, --text is already taken. I assume "--ignore-binary" or "--ignore-binary-files" would be the GNU longopt. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bad 'grep' behaviour in -CURRENT, faulty binary detection?
I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. This only seems to affect -CURRENT because -STABLE runs GNU grep 2.0. (This was committed October 28th). Now, I haven't looked at exactly how the code works, but it evidentally looks at the beginning of the file to detect it. You can use -a to override this of course. I'm not sending a PR or anything since this is 'arguable' on whether or not it's a bug or just being over sensitive. Here is an example of the output: FreeBSD 4.0-CURRENT (11NOV99): == [chenresig@karma] chenresig grep -V grep (GNU grep) 2.3 .. [root@karma] src set|grep karma Binary file (standard input) matches [root@karma] src set|head '!'=0 '#'=0 '$'=607 '*'=() -=569Xis 0=su '?'=0 @=() ARGC=0 FreeBSD 3.3-STABLE (09NOV99): = grouper# grep -V GNU grep version 2.0 grouper# set|grep grouper DISPLAY=grouper:10.0 HOST=grouper.aquarium.rtci.com grouper# set|head '!'=0 '#'=0 '$'=2647 '*'=() -=569Xils 0=-zsh '?'=0 @=() ARGC=0 BAUD=38400 -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
On Thu, Nov 11, 1999 at 03:29:05PM -0500, Thomas Stromberg wrote: I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. I've got a notion to change this. The -CURRENT grep is also very misleading w/ ``grep -l'' in that you will get "hits" on binary files because you can't see that "is a binary file" message to know better. The output of that message should be asked for with an option, not the default. I can't imagine how many people are going to get weird/eronious output from scripts now due to it. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
David O'Brien wrote: On Thu, Nov 11, 1999 at 03:29:05PM -0500, Thomas Stromberg wrote: I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. I've got a notion to change this. The -CURRENT grep is also very misleading w/ ``grep -l'' in that you will get "hits" on binary files because you can't see that "is a binary file" message to know better. The output of that message should be asked for with an option, not the default. I can't imagine how many people are going to get weird/eronious output from scripts now due to it. I think it's good as a default, nothing annoys me more then "grep -R function *" in a source directory and hitting all the binaries and getting my screen splattered with high ascii. I just wish it's binary detection was a wee bit more accurate.. I don't see what's wrong with "grep -l", it does exactly what I expected it to do. It's just expected to tell you that a file matched, not anything more (anything more could cause grave problems with scripts, including some I've written).. [root@karma] /tmp grep -l expat * expat expat-0.7.6.tar.gz wv (or maybe I'm just not understanding the issue). -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Date: Thu, 11 Nov 1999 15:29:05 -0500 From: Thomas Stromberg [EMAIL PROTECTED] I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Most likely this is because the output of your `set' command contains binary data. In the past, this has been reported by people whose `set' command would output something like this: IFS=' ^@' where the `^@' in my message denotes a single NUL byte (control-@) in the original. If this is what's happening to you, then this is quite possibly a bug in your shell, since environment variables cannot possibly contain NUL bytes in Unix. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Date: Thu, 11 Nov 1999 13:20:32 -0800 From: "David O'Brien" [EMAIL PROTECTED] I've got a notion to change this. Please don't change the algorithm to deduce which files are binary. It was the subject of much design discussion in the GNU project, and is fairly consistent across other GNU applications. The -CURRENT grep is also very misleading w/ ``grep -l'' in that you will get "hits" on binary files because you can't see that "is a binary file" message to know better. I find it useful to see the names of all files matching the pattern. This is particularly the case with grep -r. grep -lr should not output a bunch of error messages saying ``Binary file FOO skipped'', as that information is less useful than simply either reporting the file as matching, or not reporting it because it doesn't match. I can't imagine how many people are going to get weird/eronious output from scripts now due to it. The binary file behavior was added to grep in response to many user requests. Users didn't like seeing a lot of binary data sent to their screens. grep's new `-r' option seems to have contributed a lot more requests of this form. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
In the last episode (Nov 11), Paul Eggert said:
Most likely this is because the output of your `set' command contains
binary data. In the past, this has been reported by people whose `set'
command would output something like this:
IFS='
^@'
where the `^@' in my message denotes a single NUL byte (control-@) in
the original. If this is what's happening to you, then this is quite
possibly a bug in your shell, since environment variables cannot
possibly contain NUL bytes in Unix.
Aah, but 'set' prints the value of all shell variables, exported or
not. You can store any value in a shell variable. In fact, I do things
like this quite often (/bin/sh example here - zsh can do the same
without forking to set a):
a=$(cat file.gif)
size=${#a}
echo Content-Length: $size
echo Content-Type: image/gif
echo
echo -n $a
I agree that _environment_ variables can't have NULs in them.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Bonjour M. David O'Brien On Thu, Nov 11, 1999 at 03:29:05PM -0500, Thomas Stromberg wrote: I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. If I remember zsh has a "bug" and will output a NULL part of the IFS. I've got a notion to change this. The -CURRENT grep is also very misleading w/ ``grep -l'' in that you will get "hits" on binary files because you can't see that "is a binary file" message to know better. Of course, you can. But I will join my voice to Paul and ask you not to. This behaviour was a long standing request/grip where for example one would do grep pattern * and have the terminal going bananas, if pattern was detected in binary files or just by reading directories whith filenames containing *pattern* (On Solaris, you can read() a directory). The output of that message should be asked for with an option, not the default. I can't imagine how many people are going to get weird/eronious output from scripts now due to it. I don't follow your logic for '-l'. whether it is grep-2.0 or grep-2.3 They all show the filename containing a matching pattern. Grep-2.3 is just more carefull not to send binary data to stdout. In the coming 2.4, if this is such problem for you, there is en environ variable, that will restore the 2.0 behaviour(everything is text) export GREP_OPTIONS=--text -- au revoir, alain Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
Bonjour M. Peter Jeremy On 1999-Nov-12 13:13:54 +1100, Alain Magloire wrote: (On Solaris, you can read() a directory). On any real Unix you can read() a directory - `everything is a file'. Yes, and real programmers do not eat quiche either. For the Solaris comment, maybe I'm mistaken, maybe it was Linux that could not open/read directories, I do not remember. open()/read()'ing directories was never portable, even in the ranks of "real" Unix. Or perhaps depending on the filesystems it is not permitted it. You don't like opendir() and its friends *dir() ? -- au revoir, alain Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
