roy@alanine.phri.nyu.edu (Roy Smith) (12/26/89)
Is there any reason, other than a bug, why the following two
commands (extracted from a history list) should give different output?
122 15:51 grep -i 'N:.*SIRIUS' yalerem.txt
123 15:51 grep -i 'n:.*sirius' yalerem.txt
The second give no output, while the first prints:
2491 N: SIRIUS; Canicula; Dog Star; Aschere.
which, in case it's not obvious, is blank-padded to a length of 132. This
ws done on a Sun-3/50 under SunOS-3.5.2, using the standard grep supplied
by Sun. Sure looks like grep is ignoring the -i flag, doesn't it?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"kab@reed.bitnet (Kent Black,L08,640,7754072) (12/27/89)
In article <1989Dec25.210118.7946@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: > > Is there any reason, other than a bug, why the following two >commands (extracted from a history list) should give different output? > > 122 15:51 grep -i 'N:.*SIRIUS' yalerem.txt > 123 15:51 grep -i 'n:.*sirius' yalerem.txt > No. Bsd derived bug that refused to go away until ~BSD4.[2-3]; I thought old bsd-grep folded upper case in the pattern onto lower case, but not lower to upper (but see below): e.g., $ grep -i KENT /reed/etc/passwd kab:irAbYvOt4zBKQ:238:20:Kent Black,L08,640,:/u/v/kab:/bin/csh $ grep -i kENT /reed/etc/passwd $ $ grep -i KeNt /reed/etc/passwd kab:irAbYvOt4zBKQ:238:20:Kent Black,L08,640,:/u/v/kab:/bin/csh I fixed it on our vax and may have remembered backwards; patch is trivial. The bug is slowly being eradicated. Grep works as documented on at least More BSD4.3 (VAX) (and, I presume, 4.3-tahoe) SunOS 4.0 (Sun3/60) Ultrix UWS2.0 (DECstation 3100) Bug still exists for BSD4.[1-2] NeXT 1.0 (they actually reversed the behaviour, unless I've misremembered nexttues> nidump passwd . | grep -i kent kab:J5o2F5X1fbYAY:238:20:Kent Black:/u/kab:/bin/csh nexttues> nidump passwd . | grep -i KENT nexttues> Now isn't that special ;-) UTEK 4.0 (tek4317) (also reversed the behaviour) Sales Pitch: (except that it isn't for sale) Gnu grep (ggrep) has always been correct, besides which it is public domain, much faster than 4.3-grep on our vax (pointless comparison for any files I had handy on the 3100: lots of zero's ;-), has context printing (lines before, after or both), emacs-style word matching and 6 g'zillion other neat things. Use it instead, if you can. -- kab
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/05/90)
In article <1989Dec25.210118.7946@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
- Is there any reason, other than a bug, why the following two
-commands (extracted from a history list) should give different output?
- 122 15:51 grep -i 'N:.*SIRIUS' yalerem.txt
- 123 15:51 grep -i 'n:.*sirius' yalerem.txt
-The second give no output, while the first prints:
- 2491 N: SIRIUS; Canicula; Dog Star; Aschere.
-which, in case it's not obvious, is blank-padded to a length of 132. This
-ws done on a Sun-3/50 under SunOS-3.5.2, using the standard grep supplied
-by Sun. Sure looks like grep is ignoring the -i flag, doesn't it?
Funny that this BUG in the UNIX System V version of "grep" wasn't fixed
in SunOS 3.5.2, because I first heard about it from a Sun employee (at
the time). It has been fixed in any recent shipment of the BRL UNIX
System V emulation for 4.3BSD, but may not have been repaired at AT&T
yet. (They pick up my, and other, bug fixes rather erratically.)