G
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
David Candy
No there isn't. Only inferior alternatives are available.
C
C. A. Upsdell
I wish there were: for my purposes the Win98 search did a better job.
S
Sharon F
I liked the free Agent Ransack. Eventually upgraded it to the pay version
called FileLocator Pro. Both are available here: http://www.mythicsoft.com
called FileLocator Pro. Both are available here: http://www.mythicsoft.com
V
*Vanguard*
Sharon F said in news:%[email protected]:
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).
I liked the free Agent Ransack. Eventually upgraded it to the pay
version called FileLocator Pro. Both are available here:
http://www.mythicsoft.com
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).
D
David Candy
But it's stupid. It finds files it shouldn't.
1. Configure search properly.
2. Windows search also supports regular expressions.
3. Smart serarching takes longer than dumb searching.
4. Windows search can provide absrtracts of files.
Sample queries
The following provides examples of queries for various purposes.
To search for Long form Short form Result
A specific value {prop name=DocAuthor}= Dalal Ketan{/prop} @DocAuthor = Dalal Ketan Documents authored by Dalal Ketan
Values beginning with a prefix {prop name=DocAuthor} {regex}George*{/regex}{/prop} #DocAuthor George* Documents whose Author property begins with "George"
Documents with any of a set of extensions {prop name=filename} {regex}*.|(exe|,dll|,sys|){/regex}{/prop} #filename *.|(exe|,dll|,sys|) Files with .exe, .dll, or .sys extensions
Documents modified after a certain date and time {prop name=write}>96/2/14 13:00:00{/prop} @write > 96/2/14 13:00:00 Documents modified after February 14, 1996, at 13:00 Coordinated Universal Time
Documents modified after a relative date {prop name=write}> -1d2h{/prop} @write > -1d2h Documents modified within the last 26 hours
Vectors matching a vector {prop name=vectorprop}={ 10, 15, 20 }{/prop} @vectorprop={ 10, 15, 20 } ActiveX documents with a vectorprop value of { 10, 15, 20 }
Vectors where each value matches a criterion {prop name=vectorprop}>^a 15{/prop} @vectorprop >^a 15 ActiveX documents with a vectorprop value where all values in the vector are greater than 15
Vectors where at least one value matches a criterion {prop name=vectorprop}=^s 15{/prop} @vectorprop =^s 15 ActiveX documents with a vectorprop value where at least one value is 15
1. Configure search properly.
2. Windows search also supports regular expressions.
3. Smart serarching takes longer than dumb searching.
4. Windows search can provide absrtracts of files.
Sample queries
The following provides examples of queries for various purposes.
To search for Long form Short form Result
A specific value {prop name=DocAuthor}= Dalal Ketan{/prop} @DocAuthor = Dalal Ketan Documents authored by Dalal Ketan
Values beginning with a prefix {prop name=DocAuthor} {regex}George*{/regex}{/prop} #DocAuthor George* Documents whose Author property begins with "George"
Documents with any of a set of extensions {prop name=filename} {regex}*.|(exe|,dll|,sys|){/regex}{/prop} #filename *.|(exe|,dll|,sys|) Files with .exe, .dll, or .sys extensions
Documents modified after a certain date and time {prop name=write}>96/2/14 13:00:00{/prop} @write > 96/2/14 13:00:00 Documents modified after February 14, 1996, at 13:00 Coordinated Universal Time
Documents modified after a relative date {prop name=write}> -1d2h{/prop} @write > -1d2h Documents modified within the last 26 hours
Vectors matching a vector {prop name=vectorprop}={ 10, 15, 20 }{/prop} @vectorprop={ 10, 15, 20 } ActiveX documents with a vectorprop value of { 10, 15, 20 }
Vectors where each value matches a criterion {prop name=vectorprop}>^a 15{/prop} @vectorprop >^a 15 ActiveX documents with a vectorprop value where all values in the vector are greater than 15
Vectors where at least one value matches a criterion {prop name=vectorprop}=^s 15{/prop} @vectorprop =^s 15 ActiveX documents with a vectorprop value where at least one value is 15
V
*Vanguard*
David Candy said in news:[email protected]:
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
bastardized 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 bastardized 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.
But it's stupid. It finds files it shouldn't.
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!
1. Configure search properly.
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
bastardized 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 bastardized that it is a
bad joke.
2. Windows search also supports regular expressions.
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.
3. Smart serarching takes longer than dumb searching.
I see no smart option to Windows XP's Search. Maybe that is available
if you bother to waste resources running the Indexing Service.
4. Windows search can provide absrtracts of files.
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).
<snip>Sample queries
The following provides examples of queries for various purposes.
To search for Long form Short form Result
A specific value {prop name=DocAuthor}= Dalal Ketan{/prop}
@DocAuthor = Dalal Ketan Documents authored by Dalal Ketan
Values beginning with a prefix {prop name=DocAuthor}
{regex}George*{/regex}{/prop} #DocAuthor George* Documents whose
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.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.