How to use "nopath:"command?

[awqqa]

I tried nopath: command,It's seems like not work. May be i did the wrong way.
So how to use it?

[NotNull]

nopath:"part of the filename"

Will search in the filename exclusively, without looking at the path.

So, nopath:"hello" will find "c:\windows\name with hello in it.txt", but not "c:\hello\some filename.txt"

If part of the filename does not contain a space, you can leave the "" out: nopath:hello

[void]

Thank you for your feedback awqqa,

What where you expecting nopath: to do? What are you trying to do?

I'm sure we can help..


Please try toggling Match Path from the Search menu.
When enabled, Everything will search the whole path and filename.
Otherwise, Everything will only search the filename part (without the path).

[ChrisGreaves]

Please try toggling Match Path from the Search menu.

Hello. I admit that all the description of NoPath: seems counter-intuitive to me; perhaps because I was raised in ther Southern Hemisphere.

(1) "NoPath" might better be written as "NotInPath", since the modifier seems to be telling Everything "Don't try to match the given string in any part of the path"
(2) I still have to experiment with "NoPath:"ing\Tut" which I think ought to NOT match the Fullname T:\Greaves\Training\Everything\Tutorial\Searching.doc

NoPath_01.png (71.27 KiB) Viewed 2649 times

(3) While it is true to say that "toggling Match Path from the Search menu" seems to have an effect, to me it seems to have the opposite effect:-

NoPath_02.png (70.54 KiB) Viewed 2649 times

This sort-of makes sense. When I toggle OFF the menu setting (and I am still too new to think of using the menu to affect the search filter) I think of a menu switch "Match path turned on" as conveying the message "i am seriously interested in matching stuff in the path".
(4) Of course, since my filter says "NoPath:", and I am saying I am serious about it, that must mean that I am serious about my use of NoPath: in my filter.
(5) Penultimately (!) I think that there is some sort of overkill here. If I have taken the trouble to type "NoPath:" in my search filter (and I am still using on-the-fly filters, not stored filters or macro commands), it seems to me that when I state "NoPath", I must surely mean "NoPath".

(6) Finally I am not tackling the screenshot below until after I have eaten lunch and had a lie-down (grin) The screenshot below prompts me to say "You can't have it both ways"; if we are talking about "ing\Tut", then a string which does NOT match "ing\Tut" ought not to appear in the Result List.

NoPath_03.png (51.93 KiB) Viewed 2649 times

Despite my (at times) deep tenacity in some of these questions, they are questions that must strike many new users such as I, as evidenced by the originator of this topic.

As always: Please and Thank you!
Cheers, Chris
(Later) I wandered through the topic Search menu: Enable Regex, Search entry: noregex, admittedly nine year old, and now have the impression that a menu item such as MatchPath or EnableRegex is used as a global switch to disable whatever local search term (regex: or NoPath:) is found in the search items.
If so, then I still thank that "NoPath:" with a default menu switch should still work as my points (1) and (2) above suggest. C.

[NotNull]

It looks like there is a space between nopath: and train.

Usually there is no space between the modifier and the search function it's behaviour it will modify.
What happens with the following seaarch?

nopath:train

[ChrisGreaves]

It looks like there is a space between nopath: and train. Usually there is no space between the modifier and the search function its behaviour it will modify. What happens with the following search?

nopath:train

Untitled2.png (32.17 KiB) Viewed 2553 times

220 objects, same number as before, but again, I haven't checked one-for-one on object names.

I think we should leave this morning's petulant post for now.
I am going to be better served by building up a small but manageable set of folders & files to use as a benchmark for a variety of examples.
Cheers, Chris

[void]

Normally, Everything will only search the name.

using path: will make Everything search the path and name.



nopath: is only really useful when you have Match Path enabled under the Search menu and you only want to match the name.

For example:

Match Path is enabled under the Search menu and I search for:

abc 123

I really only want 123 to be in the name part, so I search for:

abc nopath:123

abc will match anywhere in the path and name.



nopath: with a path separate doesn't make any sense, as the name will typically never have a path separator.

I would recommend trying the location: search function.

The location: search function will match what is shown under the Path column.

For example:

!location:ing\tut train

[ChrisGreaves]

Hello Void. I am partway through understanding all of this, but would like to post a mid-term response to make sure that I am on the right track.

Normally, Everything will only search the name.

which is why the filter train.doc returns only 5 objects. I have NO folders where the string "train.doc" appears anywhere in the full path to the parent folder. Got It!

using path: will make Everything search the path and name.

which is why path:train.doc returns the same five objects; those five objects just happen NOT to have "train.doc" in their path, but it doesn't matter because they DO have "train.doc" in their name.

nopath: is only really useful when you have Match Path enabled under the Search menu and you only want to match the name.

This has gone into "Traps for Young Players" because these days I am still looking ONLY at the search box, and keep forgetting that an inadvertent item checked ON in the search menu is a global switch that dominates the entire search box. Correct?

For example: ... abc will match anywhere in the path and name.

.. where in your terminology, by "the path and name" you mean either one of "the Filename" or "the Full Path". Correct?

nopath: with a path separate doesn't make any sense, as the name will typically never have a path separator.

If this is true, then is there a bit of space on the ToDo list for a pre-processor to detect such semantic errors. By that I mean that if David can detect such an error in my typed search strings, then in theory David could program such detection and alert the beginner user (me!) to an apparent error? Everything is such a complex beast that the beginner is almost certain to key in filters which return results, where a semantic error returns Zero Results and the beginner is going to think "Oh! Then I don't have any of those <search string> items", when the truth is that the beginner has inadvertently asked the wrong question.

I would recommend trying the location: search function.

Gaaaaaargh! This raised my hackles a month ago! I don't like the new term "location". Still, ...
Too much text & images to post here, but in summary, this works for me.
The filter “location:ing/tut” returns no objects because in the previous filter, only one Folder was returned, and it did not show a component “ing/tut”.
Appending another search term “train” still returns no objects, because we can’t squeeze an object out of No Objects!
But when we negate the first term, we no longer have only one or zero results, but 346,624 objects to which we can then apply the second search term “train”, to reduce the number of objects back to 220.
I never thought I would be this happy to see that “220” again!!

Time for my "elevenses".
I truly do appreciate the time you spend to steer my path correct my course.
Not only that but I am aware that every minute you spend helping me is a minute taken away from your support of all the other users with more pressing issues.

Thanks again.
Chris

[void]

This has gone into "Traps for Young Players" because these days I am still looking ONLY at the search box, and keep forgetting that an inadvertent item checked ON in the search menu is a global switch that dominates the entire search box. Correct?

Yes, the search options under the Search menu will specify the default search modifiers.

For example, if you set Match Case under the Search menu, every single search term in your search will have the case: modifier applied.

The search options under the Search menu are not dominate.
You can override them with search modifiers.

For example, if you set Match Case under the Search menu, you can use nocase: to override this default search modifier.

For example: ... abc will match anywhere in the path and name.

.. where in your terminology, by "the path and name" you mean either one of "the Filename" or "the Full Path". Correct?

No, here it means specifically the path and name (aka full path)

nopath: with a path separate doesn't make any sense, as the name will typically never have a path separator.

If this is true, then is there a bit of space on the ToDo list for a pre-processor to detect such semantic errors. By that I mean that if David can detect such an error in my typed search strings, then in theory David could program such detection and alert the beginner user (me!) to an apparent error? Everything is such a complex beast that the beginner is almost certain to key in filters which return results, where a semantic error returns Zero Results and the beginner is going to think "Oh! Then I don't have any of those <search string> items", when the truth is that the beginner has inadvertently asked the wrong question.

I say typically here because names can contain path separators.

For example, if I index the path: C:\Windows
A root folder C:\Windows is created.
This root folder will have the name: C:\Windows
The name contains a: \

So the search:

nopath:C:\Windows

Might be useful here to match the root folder without searching subfolders/files under c:\windows.

I would recommend using the name: search function over the nopath: search modifier.
The name: search function ignores the path search modifier.

Gaaaaaargh! This raised my hackles a month ago! I don't like the new term "location". Still, ...
Too much text & images to post here, but in summary, this works for me.
The filter “location:ing/tut” returns no objects because in the previous filter, only one Folder was returned, and it did not show a component “ing/tut”.
Appending another search term “train” still returns no objects, because we can’t squeeze an object out of No Objects!
But when we negate the first term, we no longer have only one or zero results, but 346,624 objects to which we can then apply the second search term “train”, to reduce the number of objects back to 220.
I never thought I would be this happy to see that “220” again!!

pathpart: instead of location will also work.

I know there's a conflict with the Path property and the Path Search modifier.
I am considering replacing the path: search modifier with another name and using path: to match the path part only.

[ChrisGreaves]

nopath: is only really useful when you have Match Path enabled under the Search menu and you only want to match the name.

Here I am trying to understand "nopath" in a very simple search situation.
The only action taken by me between these three images is to turn OFF (menu) Search, Match Settings, then to turn it back to ON.

NoPath_12.png (63.14 KiB) Viewed 1631 times

In the image above I have set up the search box, and now I am showing that I have turned ON Match Path.

NoPath_13.png (56.17 KiB) Viewed 1631 times

In the second image the search string is

Code: Select all

nopath:training training 

and this returns 125 objects.

NoPath_14.png (64.15 KiB) Viewed 1631 times

In the third image the search string is unchanged, but I have checked OFF match path. Still this returns 125 objects, although I have not compared the lists one against the other for a 1-1 mapping.

Consider the third entry in all three result Lists:-

Code: Select all

T:\Pers\People\Joyelle Jolie\Microsoft Office Café webinars and training - Introducing Lucy _ Chris - cprgreaves@gmail.com - Gmail_files\

I was about to argue that regardless of whether or not Match Path was set on/off, "nopath" always turned up folders with "training" within their path.

I am an idiot!

NoPath_15.png (57.88 KiB) Viewed 1631 times

Once I ask only for "files:" I see that I was confusing "folders" with "paths".
Now I report only 118 FILES instead of 125 OBJECTS.
And not one of those 118 files has a path that contains "training"

I am going to declare THIS problem solved, and move on to the next outstanding response.

Cheers, and Thanks to all.
Chris