search folderPath:bug

General discussion related to "Everything".
Post Reply
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

search folderPath:bug

Post by uncleBob »

I want to see all files whose folderPath contains bug.
Path:Bug showes all the files I want but also shows EVERY file that contains "bug" even if the folderPath does not
void
Developer
Posts: 17152
Joined: Fri Oct 16, 2009 11:31 pm

Re: search folderPath:bug

Post by void »

Everything 1.4:

path:*bug*\*




Everything 1.5:

pathpart:bug
therube
Posts: 5056
Joined: Thu Sep 03, 2009 6:48 pm

Re: search folderPath:bug

Post by therube »

I get different results (running both under 1.5).



C:\TMP\BRU\spaces>es path:*bug*\* | wc -l
345

C:\TMP\BRU\spaces>es pathpart:bug | wc -l
1231

(for instance) 1..5 only show in 1.5, 6 shows in both 1.4 & 1.5:

Code: Select all

[1]C:\000\TMP\SEA\findbar\2\chrome\devtools\modules\devtools\client\debugger\content\
[2]C:\Local\SANDBOX\CLEAN\drive\C\Konversation\bin\Qt\chrome\devtools\modules\devtool
[3]C:\out\tookit\chrome\devtools\modules\devtools\client\aboutdebugging\src\actions
[4]C:\out\tookit\chrome\devtools\modules\devtools\client\debugger\src\actions
[5]C:\TMP\SEA\abc.net.au\chrome\X\chrome\devtools\modules\devtools\client\debugger\co
[6]C:\out\tookit\chrome\devtools\modules\devtools\client\shared\remote-debugging\adb
.
Everything path vs pathpart.png
Everything path vs pathpart.png (21.78 KiB) Viewed 944 times
therube
Posts: 5056
Joined: Thu Sep 03, 2009 6:48 pm

Re: search folderPath:bug

Post by therube »

Oh, looks like if used in 1.5 (I didn't test in 1.4), * wants to be **, somewhere.

C:\TMP\BRU\spaces>es path:*bug*\** | wc -l
1231

C:\TMP\BRU\spaces>es path:*bug**\* | wc -l
1231


(Maybe one day I'll learn the meaning of ** ;-).)
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

I am a bit lost. First, I do not understand what “code: select all” means.
But more importantly, I no longer understand what “path” means in !.5. ( It was pretty simple in 1.4)

Ipath:wia path:bug returns exactly 2 files under one folder. Other folks might need something different from "wia".)
Under 1.4 path:wia path:bug shows these full paths which seems perfectly correct to me,
path name
1. C:\Windows\debug\WIA \ wiatrace.log
2. C:\Windows\debug\WIA \ wiatrace..back.log
3. C:\Windows\debug \ WIA
Under 1.5 the same search incorrectly omits #3 EVEN THOUGH the fullypath to the folder contains both “wia” and “bug”

This is just the start of my confusion. I will explain a few other things tomorrow, but I have a very busy day today.

OOPS, i just needed to change 1.5 to be ase insensitive. I illl post more tomorrow, but I need to run now.
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

Actually, case sensitivity is only part of the problem. Under 1.5
path:bug path:WIA show all 3 objects
path:bug path:wia only shows the 2 files

It looks like wia does a case insensitive search for the file's fullname, but a case sensitive seach on the folder's fullname.

more research needed but I must run now.
therube
Posts: 5056
Joined: Thu Sep 03, 2009 6:48 pm

Re: search folderPath:bug

Post by therube »

I don't see that.

Code: Select all

C:\TMP\BRU\spaces\debug\WIA>es path:wia  path:bug c:/tmp
C:\TMP\BRU\spaces\debug\WIA
C:\TMP\BRU\spaces\debug\WIA\wiatrace.log
C:\TMP\BRU\spaces\debug\WIA\wiatrace_back.log

C:\TMP\BRU\spaces\debug\WIA>es path:wia  path:BUG c:/tmp
C:\TMP\BRU\spaces\debug\WIA
C:\TMP\BRU\spaces\debug\WIA\wiatrace.log
C:\TMP\BRU\spaces\debug\WIA\wiatrace_back.log

C:\TMP\BRU\spaces\debug\WIA>es path:WIA  path:bug c:/tmp
C:\TMP\BRU\spaces\debug\WIA
C:\TMP\BRU\spaces\debug\WIA\wiatrace.log
C:\TMP\BRU\spaces\debug\WIA\wiatrace_back.log

C:\TMP\BRU\spaces\debug\WIA>es path:wia  path:bug c:/tmp
C:\TMP\BRU\spaces\debug\WIA
C:\TMP\BRU\spaces\debug\WIA\wiatrace.log
C:\TMP\BRU\spaces\debug\WIA\wiatrace_back.log

(I'll also note that I've been confusing myself with AND/OR & really haven't thought it through, in case that is playing in.)
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

things I don't understand:
1) what does Code:Select All mean?
2) what does spaces>es mean? (corner brackets are not allowed in filenames so it must be something special.)
3) what doe wc-l mean? And is the -l case sensitive?
4) why is the following search better in 1.4 than in 1.5
image.png
image.png (76.7 KiB) Viewed 899 times
void
Developer
Posts: 17152
Joined: Fri Oct 16, 2009 11:31 pm

Re: search folderPath:bug

Post by void »

* = Match any character (except \) any number of times.
** = Match any character any number of times.
Same as Vim.

C:\Windows\* = match files/folders directly in C:\Windows
C:\Windows\** match files/folders in C:\Windows and all subfolders.


I am a bit lost. First, I do not understand what “code: select all” means.
It's just how this forum presents code.
You can ignore the "code: select all" text.
It's useful to click select all then Ctrl + C to copy to the clipboard.


But more importantly, I no longer understand what “path” means in !.5. ( It was pretty simple in 1.4)
path: has not changed.

path: = match the full path and name.
Without path: only the name part is matched.



The single
\
is most likely throwing you off.

A single
\
in Everything 1.4 does nothing and matches all files/folders.
A single
\
in Everything 1.5 matches folders only.

This can be disabled in Everything 1.5 under Tools -> Options -> Advanced -> match_folders_with_single_path_separator = false.


2) what does spaces>es mean? (corner brackets are not allowed in filenames so it must be something special.)
This is the current directory.
> is the command line prompt.
es is the Everything command line interface.


3) what doe wc-l mean? And is the -l case sensitive?
wc is the word count? program.
-l is count the number of lines command line option for wc.
| is pipe the output of ES to wc.


4) why is the following search better in 1.4 than in 1.5
Check the right of your status bar for any active search options. (Is CASE shown?)
What search options do you have enabled in Everything 1.5?
Please try unchecking Match Case from the Search menu.
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

A big part of my problem was that I always used ctrl I to switch in and out of case sensitivity.
That shortcut key no longer works in 1.5 - I must use the menu. That is simple now that I understand.

Thank you for your excellant response. It will take a while for me to digest it, but I am getting the hang of it.
Bob
void
Developer
Posts: 17152
Joined: Fri Oct 16, 2009 11:31 pm

Re: search folderPath:bug

Post by void »

To add CTRL + I to toggle match case in Everything 1.5:
  • In Everything 1.5, from the Tools menu, click Options.
  • Click the Keyboard tab on the left.
  • To the right of Show commands containing, search for:
    case
  • Select: Search | Match Case
  • Click Add....
  • Press Ctrl + I and click OK.
  • Click OK.
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

I now agree that “path: has not changed”.

But I am still missing something subtle about your statements.
1) path: = match the full path and [fully qualified] name.
2) Without path: only the name part is matched.
I understand #1 well but what do you mean by #2? It sounds wrong to me.

For instance, in all my past searches, the word path: is always implied.
For instance < xls !.xl s> finds objects like “c:\this folder contains xls files\”
< path:xls !.xls > < xls !path:.xls > all do exactly the same thing. I only use path: when it clarifies my thought process.

so what exactly did you mean by #2

Rberke (aka UncleBob)

P.S. Your software has made a tremendous improvement to my life, so I greatly appreciate your quick responses to my questions.
void
Developer
Posts: 17152
Joined: Fri Oct 16, 2009 11:31 pm

Re: search folderPath:bug

Post by void »

Thank you for your feedback Rberke,

Normally, Everything will search only the Name of your files.

Using a \ in your search will also enable full path and name matching. (the same as path:)

For example:
c:\windows\
is the same as:
path:c:\windows\
There's not much point in Everything doing a Name search for c:\windows\ as names are typically not allowed to have a \ in them.
So instead, Everything will implicitly match the full path and name.
froggie
Posts: 302
Joined: Wed Jun 12, 2013 10:43 pm

Re: search folderPath:bug

Post by froggie »

For instance, in all my past searches, the word path: is always implied.
For instance < xls !.xl s> finds objects like “c:\this folder contains xls files\”
< path:xls !.xls > < xls !path:.xls > all do exactly the same thing. I only use path: when it clarifies my thought process.
Just a thought: do you have "Match Path" checked under "Search" in the menu bar? That would give the result you are describing.
uncleBob
Posts: 12
Joined: Fri Jan 20, 2023 11:05 pm

Re: search folderPath:bug

Post by uncleBob »

Aha!! On my computer both 1.4 and 1.5 had "match path" turned on. Thank you Froggie.

That setting causes full path to be the default search which makes “path:” almost entirely superfluous.

So, I now understand exactly what was meant by
2) Without path: only the name part is matched.

Thank you both for the clarification.
Post Reply