i think the real point to be noted about this thread is that you are far
better using your distro's tools to see what is in a particular package.
I covered this in my newbie talk (slides to be posted later today).

in particular, suse, redhat, fc, mandrake, and others all package in rpm.
assuming the package name is mozilla-firefox [1][2]:

rpm -ql mozilla-firefox|grep icon

is more accurate than 

locate|grep icon|grep firefox

don't forget window managers and other packages sometimes install a set
of generalised icons. eg netscape icons exist on my system even though I
have never installed netscape.


[1] it might not be, on suse it is MozillaFirefox, which I could
ascertain if i didn't already know by searching for the package name in
Yast, or even quicker:

rpm -qa|grep -i fire

-qa = query all packages (gives a list of every installed package)
grep -i = case insensitive search (catches the upper case F in MozillaFirefox)

[2] Yast, urpmi, yum, apt-rpm and other package management tools that
appear in these distros are all add-ons/enhancements to rpm. apt-rpm was
ported from debian by Connectiva, a Brazillian distro.

On Thu, 18 Nov 2004 07:53:39 +1300
Alasdair Tennant <[EMAIL PROTECTED]> wrote:

> On Wed, 17 Nov 2004 06:28:17 +1300
> Roger Searle <[EMAIL PROTECTED]> wrote:
> 
> > SuSEbox:/home/roger # locate icons | grep firefox | less
> > locate: /var/lib/locatedb: No such file or directory
> 
> Erm . .. Jus realised that this thread had continued well after I wrote
> this reply.  Well here is, anyway . ..
> 
> I find that it pays to search on the most generic term possible first,
> so 
> 
>       locate icon | less
>                   ^       
> 
> should make a 'wider' search, which you can refine by yanking back the
> command line and modifying it, in the knowledge that what you want is
> probably in there somewhere.  You can also search from within 'less' by
> using '/[search pattern]'. You don't know whether the icon file is named
> firef, ff, ffox, firefox, etc., or what the extension is.  
> 
> These methods tak a little longer, but it's almost always quicker to
> 'home in' from a wide search to a narrow one, rather than risk missing
> the target altogether - so you don't know whether or not it exists.   
> 
> Note Nicks reply too, to run 
> 
>       updatedb
> 
> which logs the entire filesystem into its database.  This is a snapshot,
> and doesn't get updated when something changes.  It's advantage is that
> finding a file is much faster than a real file search, and it's much
> friendlier at using wildcards. 
> 
> -- 
> Alasdair Tennant
> Dunedin
> New Zealand

-- 
Nick Rout <[EMAIL PROTECTED]>

Reply via email to