|
|
|
Re: Is there a better search program available for XP? |
| message from Sharon F on 30 May 2004 |
I liked the free Agent Ransack. Eventually upgraded it to the pay version
called FileLocator Pro. Both are available here: http://www.mythicsoft.com
|
| *Vanguard* replied to Sharon F on 30 May 2004 |
Ditto on Agent Ransack. Currently using the freebie version. Much
better than Search included in Windows. One, it finds the files that
Search won't that do exist and have no special attributes (hidden and
system) on the files and folders. Don't know why it can't find some
files, even when you start the search from the very folder in which
exists the file, although you can see them using Explorer and in a DOS
shell. Two, you get to use regular expressions for better search
criteria. Three, it is a much faster search engine and is almost
instantanous on subsequent same-session searches. Four, the paid
version includes a preview pane when selecting items found in the
search. Under Windows 2000, searching for text within files actually
would do that but the Search in Windows XP will only look in some
filetypes for the specified search string (see
http://support.microsoft.com/?id=309173 so, five, the Windows XP Search
will not look in many filetypes to find the text string you want to
search for but Agent Ransack will.
I also tried freebie version of InfoRapid Search & Replace but didn't
like it (don't remember the reason other than maybe it kept inserting a
promo to buy it at the top of the search results).
|
| *Vanguard* replied to *Vanguard* on 31 May 2004 |
Never done that for me. But then obviously it finds what you tell it to
find. Like you said next, "configure the search properly" (by using a
proper regular expression). If you do a search on "ipconfig" then it
will find files like "abcipconfig123.errlog.txt" and "ipconfigipconfig"
because you did not specify that the substring must start at position 1
and that nothing must follow or what exactly follows. Instead you would
need to search on "^(ipconfig)\." if that is what you want to find where
the string begins in position 1, contains only one instance of
"ipconfig" and is followed by one occurrence of the "." character but
you don't care about the filetype (or whatever substring follows the
period character). You can tailor the regular expression further to
narrow down the matches but the point is for the *user* to find the file
and they'll likely be able to pick it out if the list of matches is
small. It isn't always necessarily to find only 1 match, but if needed
then you could search on "^(ipconfig)\.(exe)$". I certainly don't need
the constant overhead of the Indexing Service along with catalog
creation and maintenance and having to learn a query language just to
find one file. While you're doing all that, I've finished that task and
long gone onto something else.
Also, I would rather have the tool find *more* matches than *MISS* some
or all of them! With NO text string to search on where I am just
searching on the filename, I can repeatedly get the Search tool in
Windows XP (with all the advanced options enabled except case and tape
backup) to NOT find a file that I can readily see in Explorer, a DOS
shell, and using Agent Ransack (and no problem with permissions,
either). It's like shoving your key ring into your mouth and mumbling
that you can't find your keys. It's right there, dummy, so find it!
According to the help for Search, "*" and "?" are it for wildcard
characters and regular expressions are not listed, explained, or even
mentioned. If you want, you can configure Agent Ransack to use the same
****ized wildcarding that is typical of those used at the DOS prompt.
Although my primary platform is Windows, I have used Unix on occasion in
the past to realize that what Microsoft considers wildcards and
[ir]regular expressions to be so limited and ****ized that it is a
bad joke.
And where in its help are regular expressions defined, listed, or even
mentioned? It supports a database query language to interrogate the
catalogs created by the Indexing Service. A database query language is
NOT the same as regular expressions.
I see no smart option to Windows XP's Search. Maybe that is available
if you bother to waste resources running the Indexing Service.
Where would those abstracts be viewed? The leftside pane is usurped by
the Search tool so the preview of the file is not visible (and would be
too tiny, anyway). Again, sounds like something you have to waste
resources by leaving the Indexing Service always running, and which
would only be usable for a limited set of filetypes (since it doesn't
look inside of other filetypes).
Sure looks like you are talking about searching through a catalog
generated by the Indexing Service. So to provide enhanced searching
capabilities the Windows XP Search needs to rely on a constantly running
Indexing Service which will often interfere with the user's use of their
system because of all the disk accesses. In order to make Search look
good, it has to build catalogs which only catalog some filetypes. On a
host used as a file server, using the Indexing Service may provide some
value, but not on the typical desktop. Also, rather than use regular
expressions in *file* searches, you need to learn Microsoft's query
language for searching through their databases (i.e., catalogs). While
database queries can be more potent than regular expressions, they go
far beyond what the end users wants and needs. I'm still hunting around
in the help for Search and under Start -> Help trying to find info on
all the query commands possible when using Indexing Service but haven't
found any help yet. Maybe the help content changes if you have the
Indexing Service running instead of disabled.
Regular expressions for a simple file search are not the same as query
language directives used in a database search. I don't expect to learn
ISQL in order to just search for a file. Yes, perhaps the query
language supports regular expressions within its directives but that is
secondary to the fact that first you need to learn the query language.
There's a reason why most users disable the Indexing Service: it is far
beyond their needs when just trying to find a file, but unfortunately
the simple interface to Search will sometimes miss files and it doesn't
let you use regular expressions to give a bit more power in your search
(and using a query language to search databases that need to be
constantly updated is like using a intercontinental ballistic missile to
get to work). More power isn't necessarily a good thing and can get in
the way. Why use Access or Excel when Calculator is sufficient to add 2
numbers provided it actually gets the correct result instead of
"missing" it, and if you find Calculator doesn't work right then you get
another tool but not necessarily something that is far extreme beyond
your needs.
You think consuming resources to run the Indexing Service, having to
define and configure the catalogs, and learning a database query
language is really easier than a product that will perform better file
searches and gives you regular expressions? The Indexing Service is not
targeted for use by end users. I sincerely doubt the OP was interested
in the Indexing Service, catalogs, and the query language. If a user
asks how to search an address book, I don't go suggesting that they
employ SQL, define a database, and write queries to the database to
search it.
|
|