Fault in my reasoning for ANDed search terms?

[ChrisGreaves]

T:\Greaves\Training\Everything\Tutorial\Keyboard Shortcuts.doc

Above is the drive, path, name, and extent of an MSWord document on my encrypted drive. The file exists; I have just opened it in MSWord2003.
Note the space within the Name portion of the file’s full name.
I was trying to locate the file using Version 1.5.0.1337a (x64)
T:\Greaves\Training\Everything\Tutorial\Keyboard Shortcuts.doc
I paste this string of 62 characters into the search box of Everything, and receive 1 object as the result.

Traps_02.png (36.81 KiB) Viewed 325 times

This is what I expected as I pasted the full filename into the search box. Exactly one result, since I had specified a drive letter in the leading part of the search string. Every file on my system should have a unique filename, and a file on a specified drive (in this case T:) should have a filename that is unique to that drive.

I wanted to demonstrate Everything’s ability to locate a file by narrowing down a number of simple search terms.

I knew that I had written a document on keyboard shortcuts, so I am not surprised that the two sub-strings separated by a space character have located the specific file.
T:\Greaves\Training\Everything\Tutorial\Keyboard
AND
Shortcuts.doc

I thought that I might split that first long sub-string into two shorter sub-strings:-
T:\Greaves\Training\Everything\Tutorial
AND
Keyboard
AND
Shortcuts.doc

Traps_03.png (37.7 KiB) Viewed 325 times

I think that I am happy with this result (2 objects). I would explain it away as saying “On drive T:, in the folder Greaves, in the folder Training, in the folder Everything” (or alternatively “on Drive T: in the folder tree of Greaves\Training\Everything”) AND must have the string “keyboard” somewhere in the filename AND must have the string “shortcuts” somewhere in the filename.

Traps_04.png (26.09 KiB) Viewed 325 times

I am surprised to find ZERO results when I separate another sub-string in the search box:-
T:\Greaves\Training\Everything
AND
Tutorial
AND
Keyboard
AND
Shortcuts.doc

I am surprised because I had reasoned that the unique filename “T:\Greaves\Training\Everything\Tutorial\Keyboard Shortcuts.doc” ought to satisfy a search constraint that says:-
Has “T:\Greaves\Training\Everything” AND “Tutorial” AND “Keyboard” AND “Shortcuts.doc” in the filename.
I feel that this is something I should have understood some two years ago, but clearly there is a flaw in my reasoning that “You can narrow down a search result by adding more ANDed search terms”.

Thanks in advance for any counseling on my belief in the And-logic of search terms.
Cheers, Chris

[NotNull]

First of all: Welcome back!

Your reasoning is largely correct. One minor detail:
Everything will search for matches in the filename (without path), unless it is told to look in the path too.
There are a couple of ways to make Everything search the path (too):

• Enable Match Path (Menu => Serach => Match Path).
  All 'words' will be searched in filename as well as its path.
• Use a path separator ("\")in the search [1]
  The entire 'word' containing the path separator will be searched in filename as well as its path.
• Use the path: modifier.
  The 'word' following path: will be searched in filename as well as its path.
• Use the global modifier ::path:.
  All 'words' following ::path: will be searched in filename as well as its path.
• Use wildcards.
  ** will search over the entire path: **everything**shortcuts.doc
  (btw: * stops matching at a "\" ; ** matches backslashes too)

A 'word' is the text up until the next space character.
Use double quotes around text containing a space to prevent Everything from seeing a space as an AND:
"program files (x86)"

So this:

I am surprised to find ZERO results when I separate another sub-string in the search box:-
T:\Greaves\Training\Everything
AND
Tutorial
AND
Keyboard
AND
Shortcuts.doc

Will search Keyboard in the filename, instead of the path.

Personally -- because lazy -- I would search for:

\keyboard\ shortcuts.doc

: Find all shortcuts.doc files that have \keyboard\ in their path somewhere.



[1] Instead of a backslah, a forward slash can also be used, provided that Replace forward slashes with backslashes is set (Menu => Tools => Options => General => Search )



EDIT: Added a fifth option to search the path.

[ChrisGreaves]

Your reasoning is largely correct. One minor detail:

How I adore this approach! Your are almost right except ...

Everything will search for matches in the filename (without path), unless it is told to look in the path too. ... Enable Match Path (Menu => Search => Match Path). ...

This is how I thought it worked; I was in error. "Close, but no cigar".

At another time and in another place I shall ask how MatchPath<==OFF came to be the default, but for now I shall offer my thoughts on training an absolute beginner:-

For someone starting from scratch, the view is, quite reasonably, to search for files by file name. And we hope to turn up an explicit file. We start by thinking what the file might be called, or perhaps where it might be found.
In my case I think “Training” and immediately “and Everything” because I am dredging my material for something that I think might suit you.
In your case you think “recipes”. So our initial impulse is to search by individual character-strings separated by spaces.

So to my mind, now, thanks to NotNull, the best way to start learning about Everything is to use the “atomic” parts of a search string.
“T:\Greaves\Training\Everything\Tutorial\Keyboard Shortcuts.doc” turned out to be where I wanted to end up. It was “the mountain top whose name I did not know, but which I wanted to be at the top of” .

And so had I started by setting MatchPath<==ON
Training
And then added
Everything
and kept going, that might have made a great deal more sense to you and of course to any other beginner.

Traps_05.png (46.66 KiB) Viewed 294 times

In this image I faked the search by taking the known target and replacing all delimiters (<slash> and <period>) by space characters.
As always my goal is NOT to isolate the individual file by magic, but to narrow down the results to a dozen or so so that <Content:> can be employed.

Thanks again to NotNull
Cheers, Chris