Xref: utzoo comp.unix.wizards:9246 comp.unix.questions:7527
Path: utzoo!attcan!uunet!mcvax!eutrc3!wswietse
From: wswietse@eutrc3.UUCP (Wietse Venema)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: grep replacement
Message-ID: <239@eutrc3.UUCP>
Date: 10 Jun 88 20:34:23 GMT
References: <7882@alice.UUCP> <5630@umn-cs.cs.umn.edu> <6866@elroy.Jpl.Nasa.Gov> <2978@ihlpe.ATT.COM> <1463@laidbak.UUCP> <4524@vdsvax.steinmetz.ge.com> <2274@isis.UUCP> <7207@watdragon.waterloo.edu>
Reply-To: wswietse@eutrc3.UUCP (Wietse Venema)
Organization: Tech. Univ. Eindhoven, The Netherlands
Lines: 22

In article <7207@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes:
}Grep should, where reasonable, not be bound by the notion of a 'line'.
}As a concrete expression of this, the useful grep -l (prints the names of
}the files that contain the string) should work on any kind of file.  More
}than one existing 'grep -l' will fail, for example, to tell you which of a 
}bunch of .o files contain a given string.  Scenario - you're trying to
}link 55 .o's together to build a program you don't know that well.  You're
}on berklix.  ld sez: "undefined: _memcpy".  You say: "who's doing that?".
}The source is scattered inconveniently.  The obvious thing to do is: 
}grep -l _memcpy *.o
}That this often will not work is irritating.
}Tim Bray, New Oxford English Dictionary Project, U of Waterloo

	nm -op *.o | grep memcpy

will work just fine, both with bsd and att unix.

	Wietse
-- 
uucp:	mcvax!eutrc3!wswietse	| Eindhoven University of Technology
bitnet:	wswietse@heithe5	| Dept. of Mathematics and Computer Science
surf:	tuerc5::wswietse	| Eindhoven, The Netherlands.