🚀 go-pugleaf

As a follow-up to my earlier posting regarding the bug in fgrep(1),
I have isolated the bug down to the following 'minimal' set of strings.

In the 'strings' file:
abcd
cef
bg

In the 'text' input file:
abcef

Then, enter the command:

fgrep -f strings text

If you have the bug, fgrep will fail to match the string 'cef' to the text line.
-- 
Bob Best
uucp: ...{trwrb,hplabs}!felix!dhw68k!bob	InterNet: bob@dhw68k.cts.com

Actually, the following reduced set of strings is sufficient:

in 'strings':
abcd
ce
bf

in 'text':
abce

then:
fgrep -f strings text

-- 
Bob Best
uucp: ...{trwrb,hplabs}!felix!dhw68k!bob	InterNet: bob@dhw68k.cts.com

In article <10535@dhw68k.cts.com> bob@dhw68k.cts.com (Bob Best) writes:
>The enclosed shar file contains a set of files that provide evidence that
>the SYSV fgrep(1) is broken.

Geoff Whale published fixes for this bug, and Gould CSD found yet another
problem, some time before 1-Nov-1986 when I installed the fixes in the
BRL System V emulation (along with case folding bug fixes and speed-ups
from Guy Harris).  Get them from there...

if its any consolation, my new grep (which right now is probably
the grep for system v, rel 4 if all goes well) does not exhibit
this bug. in fact, fairly early on in my testing i discovered
that fgrep was less reliable than my grep.

g'day all,

	try the following (On NCR Tower SysV.2):-

	$ ps -ef | grep xxxxxx
Gives->	treval  8911  8910  4 13:12:01 X00t  0:00 grep xxxxxx
	$ ps -ef | fgrep xxxxxx
Gives->	$


	Is this a related problem to the grep(1) bug? 
	Here fgrep(1) seems to be the one that is broken. 
	Is this because fgrep forks and the arguments no longer appear in the 
	argument space? If not, why not?

	Cheers, treval

	PS: (To NCR...)

	When will SysV.3.x be available for the Tower? 
	And why are the Tower machines so expensive? (All they are is an
	Atari ST in a big box after all ;->)
-- 
<==============================================================================>
 Trevor Luker		        		CCE Luxembourg
 treval@tauros.UUCP				Batiment Jean Monnet, C2/60
 ...!mcvax!prlb2!tauros!treval			L-2920 Luxembourg

In article <458@tauros.UUCP>, treval@tauros.UUCP (Trevor Luker) writes:
] g'day all,
] 
] 	try the following (On NCR Tower SysV.2):-
] 
] 	$ ps -ef | grep xxxxxx
] Gives->	treval  8911  8910  4 13:12:01 X00t  0:00 grep xxxxxx
] 	$ ps -ef | fgrep xxxxxx
] Gives->	$
] 
] 

I tried the same thing on Xenix 2.2.3.  It worked fine.

Jonathan Bayer			(I don't know, I only work here)

In article <458@tauros.UUCP> treval@tauros.UUCP (Trevor Luker) writes:
>g'day all,
>
>	try the following (On NCR Tower SysV.2):-
>	$ ps -ef | grep xxxxxx
>Gives->	treval  8911  8910  4 13:12:01 X00t  0:00 grep xxxxxx
>	$ ps -ef | fgrep xxxxxx
>Gives->	$
>
>	When will SysV.3.x be available for the Tower? 
>	And why are the Tower machines so expensive? (All they are is an
>	Atari ST in a big box after all ;->)

The problem shown above has been corrected by the TOWER 32/4xx-6xx Operating
System Release 2.00.00 software.

UNIX(tm) V.3.x will be released on the TOWER 32-4xx-6xx platform with the
3.00.00 Operating System Release.  Consult with your local sales & support
office for definitive product content and release dates.

+------------------------------------------------------------------+
|Sam Vause, NCR Corporation, Customer Services - TOWER Support	   |
|3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953   |
|                                vause@cs-col.Columbia.NCR.COM     |
|		...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause      |
+------------------------------------------------------------------+

In article <163@ispi.UUCP>, jbayer@ispi.UUCP (id for use with uunet/usenet) writes:
> In article <458@tauros.UUCP>, treval@tauros.UUCP (Trevor Luker) writes:
> ] 	try the following (On NCR Tower SysV.2):-
> ] 	$ ps -ef | grep xxxxxx
> ] Gives->	treval  8911  8910  4 13:12:01 X00t  0:00 grep xxxxxx
> ] 	$ ps -ef | fgrep xxxxxx
> ] Gives->	$
> I tried the same thing on Xenix 2.2.3.  It worked fine.

Ditto on AT&T 3B20 running SVR2.

Are you sure it isn't fgrep munging its argument somehow, or the ps finishing
(with buffered output waiting to come through the pipe) before the fgrep has
been exec'd?  Try these:

$ ps -ef | grep ps
$ ps -ef | fgrep ps

$ sleep 30 xxxxxx &	#sleep ignores extra arguments
$ ps -ef | fgrep xxxxxx	#do you see at least the sleep process?
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|