Modifiers vs Functions

[Stamimail]

What is the difference between Modifiers and Functions?

[void]

Modifiers are flags for functions.
Functions are how the specified "search term" is used to compare files.

Everything searches are broken into "search terms" by using spaces or |.
For example, the search ABC 123 is two search terms: ABC AND 123.

Every search term in Everything has a list of modifiers (zero or more) and one function associated with it.

If the function is not specified the default search function is used depending on what search settings you have (match path, match case etc...).
Most likely all search settings will be disabled and Everything will use a case/diacritic insensitive STRSTR function.

For the search: ABC 123, Everything would interpret this as:
nocase:nodiacritics:nopath:nowholewords:noregex:STRSTR:ABC nocase:nodiacritics:nopath:nowholewords:noregex:STRSTR:123
Where STRSTR is the default search function.

Notes:
Some modifiers do nothing for some functions, for example: regex: ignores the wholeword: modifier. dupe: ignores the case: modifier.
When working with functions that have a "text" search term, generally, case:, path:, wholeword:, diacritics: and regex: modifiers are supported.
For example, regex:content:^ABC to search for files that start with the content ABC.

Not all functions take a search term, such as dupe:.
If you do specify a search term, it is split into two, eg: dupe:ABC becomes dupe: AND ABC

By default, content: will not use a wildcard comparison, if you want to do a wildcard content comparison, use wildcards:content:ABC*123

All functions support the file: or folder: modifier to limit results to files only or folders only.

list of modifiers and functions.

[burgundy]

All functions support the file: or folder: modifier to limit results to files only or folders only.

Should path: also be added to file: and folder: ?

I am trying to see if I've understood this correctly!

[raccoon]

path: is the opposite of nopath:
just like wholeword: is the opposite of nowholeword: and case: is the opposite of nocase:

file: and folder: simply assert which databases should be read from, since internally Everything stores all file objects and all folder objects into two distinct tables. To the end user, they feel like Filters.

[ChrisGreaves]

Not all functions take a search term, such as dupe:.
If you do specify a search term, it is split into two, eg: dupe:ABC becomes dupe: AND ABC

Five years old, I know, but nonetheless this goes into my "Traps For Young Players" (grin)

Is there/have you a list of current 1.5 functions that do NOT take a parameter?

Dupe is a good example, but becomes a trap when used as if Dupe: could take an argument, as you pointed out.
Thanks, Chris

[void]

dupe: does take an optional parameter now.

Here is a list of search functions that don't accept parameters:

• ancestorfilelist1:
• ancestorfilelist2:
• ancestorfilelist3:
• ancestorfilelist4:
• ancestorfilelist5:
• ancestorfilelist6:
• ancestorfilelist7:
• ancestorfilelist8:
• ancestorfilelist9:
• attribdupe:
• attributedupe:
• attributesdupe:
• childfilelist0:
• childfilelist1:
• childfilelist2:
• childfilelist3:
• childfilelist4:
• childfilelist5:
• childfilelist6:
• childfilelist7:
• childfilelist8:
• childfilelist9:
• dadupe:
• dateaccesseddupe:
• datecreateddupe:
• datemodifieddupe:
• dcdupe:
• descendantfilelist0:
• descendantfilelist1:
• descendantfilelist2:
• descendantfilelist3:
• descendantfilelist4:
• descendantfilelist5:
• descendantfilelist6:
• descendantfilelist7:
• descendantfilelist8:
• descendantfilelist9:
• dmdupe:
• dupeattrib:
• dupeattribute:
• dupeattributes:
• dupeda:
• dupedateaccessed:
• dupedatecreated:
• dupedatemodified:
• dupedc:
• dupedm:
• dupename:
• dupenamepart:
• dupepath:
• dupesize:
• dupestem:
• empty:
• filelist0:
• filelist1:
• filelist2:
• filelist3:
• filelist4:
• filelist5:
• filelist6:
• filelist7:
• filelist8:
• filelist9:
• filterbar:
• filterssidebar:
• folderssidebar:
• groupcolors:
• header:
• isbmp:
• isgif:
• isico:
• isjpeg:
• isjpg:
• isopen:
• ispcx:
• ispng:
• ispsd:
• isrunning:
• istga:
• istif:
• istiff:
• iswebp:
• localdb:
• menubar:
• mixsort:
• namedupe:
• namepartdupe:
• nofilterbar:
• nofilterssidebar:
• nofolderssidebar:
• nogroupcolors:
• noheader:
• nomenubar:
• nomixsort:
• noontop:
• nopreview:
• nosortmix:
• nostatusbar:
• offline:
• omitresults:
• online:
• ontop:
• parentfilelist0:
• parentfilelist1:
• parentfilelist2:
• parentfilelist3:
• parentfilelist4:
• parentfilelist5:
• parentfilelist6:
• parentfilelist7:
• parentfilelist8:
• parentfilelist9:
• pathdupe:
• preview:
• randomize:
• root:
• row:
• secondarysortascending:
• secondarysortdescending:
• shuffle:
• siblingfilelist0:
• siblingfilelist1:
• siblingfilelist2:
• siblingfilelist3:
• siblingfilelist4:
• siblingfilelist5:
• siblingfilelist6:
• siblingfilelist7:
• siblingfilelist8:
• siblingfilelist9:
• sizedupe:
• sizefilelist0:
• sizefilelist1:
• sizefilelist2:
• sizefilelist3:
• sizefilelist4:
• sizefilelist5:
• sizefilelist6:
• sizefilelist7:
• sizefilelist8:
• sizefilelist9:
• sortascending:
• sortdescending:
• sortmix:
• statusbar:
• stemdupe:
• tempomit:
• treeview:
• treeviewnosubfolders:

[void]

Should path: also be added to file: and folder: ?

path: will match the path and name.
Otherwise, only the the name is matched.

You can add path: to file:/folder:

The order of search modifiers does not matter.

The following are the same:
path:file:
file:path:



Not all search functions support the path: search modifier.

For example:

path:ext:*.mp3

ext: takes a list of extensions.
Matching the full paths doesn't make much sense, we only need the name, so the path: search modifier is ignored.

[ChrisGreaves]

dupe: does take an optional parameter now.
Here is a list of search functions that don't accept parameters:

Thank you David. I already know none of these 148 additions to my vocabulary!
Cheers, Chris

[ChrisGreaves]

file: and folder: simply assert which databases should be read from, since internally Everything stores all file objects and all folder objects into two distinct tables. To the end user, they feel like Filters.

Modifiers are flags for functions.

When I rose this morning I thought of a Modifier as a restriction, a narrowing-down of the original search term.
The only checked-on Search menu item is “Everything”. (Will we get a “reset to defaults” item at the head of the Search menu?)

I understand that the modifiers “file:” and “folder:” serve to restrict Everything to one or the other of two databases. (Why is it that “file:folder:” in combination do not eliminate both databases from contention?)(And why does noFile:noFolder:train return a different set of results from noFolder:NoFile:train ?)
I think I understand that the modifier “path:” tells the search engine to examine only the path of the object.

With this possibly shaky foundation I ran three filters:-
Train 220 objects

NoPath_01.png (51.99 KiB) Viewed 4351 times

Path:train 8,426 objects

NoPath_02.png (53.29 KiB) Viewed 4351 times

Nopath:train 220 objects

NoPath_03.png (55.14 KiB) Viewed 4351 times

Clearly “path:” is not a restrictive modifier.

I do NOT maintain that the results of the first and third filters are the same, only the count of objects is the same (220 objects), although I suspect that they are the same set of objects.

If I am making any progress at all:-
(a) The first search, plain-Jane “train” is by default searching only things that Void calls Full Path. My folder “T:\Greaves\Training” contains 6,567 files and 658 folders, yielding 7,225 objects; I suspect that my Model Railways (a.k.a.toy trains) efforts account for most of the remainder.
I don’t understand why only 220 objects are returned.
(b) The second search “Path:Train” focuses our attention on the Path, which I take to mean everything after the drive letter and before the bit that Void calls Name.
I am not surprised to see 8,426 objects here.
(c) The third search “Nopath:train” must restrict the searching to the drive letter and/or the Name

NoPath_04.png (44 KiB) Viewed 4351 times

(d) Yet when I right-click OpenPath on one of the objects that is a folder, the Path must surely be “T:\Pers\Places\AutoTrain” with corresponding FullPath examples such as “T:\Pers\Places\AutoTrain\Breakdown.xls”. And I note that the string "train" appears not at all in ther name or the drive, only in the folder, which is identified as a Path!
(e) How is it that by specifying NoPath: I have managed to locate an object whose Path obviously contains “train” when the Name obviously does not?

I concede that I am still ignorant; I am dreaming up example filters (function and modifiers only at this stage) and trying to make sense of the Results List.

This long post says "I have something basically wrong with my thinking"; I am not in desperate need of identifying a small set of objects related to "trains".
Cheers, Chris

[NotNull]

There are a few new (to me) functions in that list.
Some are self-explanatory (like header: / noheader: ), but what should iswebp: / ispsd: / .. do?

[void]

Will we get a “reset to defaults” item at the head of the Search menu?

Alt + Home
-or-
History menu -> Home

why does noFile:noFolder:train return a different set of results from noFolder:NoFile:train ?

Because these are really filesonly: and foldersonly: and one overwrites the other.
The next alpha update will match no results is you use nofolder:nofile: or filesonly:foldersonly:

I think I understand that the modifier “path:” tells the search engine to examine only the path of the object.

No, the path: modifier tells Everything to match the path and name.

Use the pathpart: search function to match only the path part of the object.

(a) The first search, plain-Jane “train”

This will only match files/folders containing train in the name part. (not in the path)

(b) The second search “Path:Train”

This will match files/folders with train in the path and name.

(c) The third search “Nopath:train”

nopath:train is the same as train

This will only match files/folders containing train in the name part. (not in the path)

(d) Yet when I right-click OpenPath on one of the objects that is a folder

Open Path will open the path part in Windows Explorer and select the file/folder that was selected in Everything.

(e) How is it that by specifying NoPath: I have managed to locate an object whose Path obviously contains “train” when the Name obviously does not?

I think you will find the name does contain train and that the path may also contain train.
nopath:train will not prevent files/folders from showing up in your results if the path part contains train.

To do this, use:
!pathpart:train

but what should iswebp: / ispsd: / .. do?

These search functions are from Everything 1.4. (there might be a few additions for Everything 1.5)
These functions can be used to validate jpg, png files etc.
isjpg: will match files that contain a valid jpg signature.

For example:

*.jpg !isjpg:
returns jpg files that are not really jpg files.

It's functionally identical to:

*.jpg file-signature:!=image/jpeg

[NotNull]

These functions can be used to validate jpg, png files etc.
isjpg: will match files that contain a valid jpg signature.

Right! It's dawning now.
I can even remember again us discussing this long time ago ... Thanks!

[ChrisGreaves]

Will we get a “reset to defaults” item at the head of the Search menu?

Alt + Home
-or-
History menu -> Home

Menu_Search_01.png (58.88 KiB) Viewed 4158 times

Thanks void, but I was looking for some magic to reset all the options to defaults, which in the example shown above would return “Match Path” and “Ignore White Space” to be checked OFF.

Menu_Search_02.png (45.26 KiB) Viewed 4158 times

The equivalent of the “Restore Defaults” command button in Tools, Options.

I have been working through the rest of your excellent reply, but have decided to wait because I went around and around in circles with path/path-part/ and the like. I ended up writing:

"I think we should drop this part for now. I can’t stop that “Administrator” status, and I think that I am confusing myself. Let’s wait until (a) the new system arrives, all shiny and clean and (b) I have set up a well-defined folder structure somewhere with a manageable number of set pieces. (I can create two data partitions, one for my encrypted Real data, and a smaller (5GB) partition for use as a sand-pit; because I am just about hammering Everything to death here. Mea Culpa!"

In the meantime, here's one of the hurdles that tripped me up this morning while rummaging around with Path::-

SimpleSearch05.png (52.67 KiB) Viewed 4158 times

I have a weird feeling that Everything is overstepping the mark when it pretends that "t r" matches "tr" when using my search string.
Cheers, Chris

[NotNull]

TIP: If you get unexpected results: check the statusbar.
TIP2: If you don't get unexpected results: still check the statusbar from time to time

In this case the statusbar shows !SPACE, which indicates that Ignore white-space is enabled (undeer menu:Search).
And as a faithful search companion, Everything does just that, making "t rain" equivalent to "train"

[ChrisGreaves]

TIP: If you get unexpected results: check the statusbar.
TIP2: If you don't get unexpected results: still check the statusbar from time to time
In this case the statusbar shows !SPACE, which indicates that Ignore white-space is enabled (under menu:Search).
And as a faithful search companion, Everything does just that, making "t rain" equivalent to "train"

We will debate "faithful" vs. "fanatical" in another thread ...

ResultList_01.png (53.55 KiB) Viewed 4010 times

I will begin documenting "Result List - Status Bar - Section one" this afternoon.
In the meantime let's all keep our fingers crossed that my new laptop has a large enough screen to accommodate the status bar in Everything.

I truncated my addition of terms to the status bar because when I checked ON Search, Regex, Everything stole some of my accumulated status bar terms, which i thought was particularly clever petulant given the effort I had put into amassing My Very First Example.

NotNull, thanks for your continuing efforts at my tuition.
Cheers, Chris

[NotNull]

thanks for your continuing efforts at my tuition.

Yes, of course! All for the (very!) good cause (when time permits)

I will begin documenting "Result List - Status Bar - Section one" this afternoon.

In that case: a couple of points that might not be obvious at first sight:
- You can right-click the status bar to toggle search options on/off (among other things)
- Double-clicking (for example) !SPACE in the statusbar will toggle it off

There is a lot more going on in the statusbar, but that might be less relevant for 'the big picture'


As Everything has a very clean interface, it's statusbar is an important way to communicate with us.

[ChrisGreaves]

These functions can be used to validate jpg, png files etc.
isjpg: will match files that contain a valid jpg signature.

Hi Void. I have attached a Word/VBA utility function from a long time ago.
Back around 1996 I learned the positions of magic bytes that revealed whether or not a file contained a WordPerfect 5.1(DOS) file.

(1) Is this similar in manner to how you test for isJPG? I noticed a list of IS functions in this post.
(2) Is there a possibility for the user to specify a type of file by searching the Content for such a string?

Code: Select all

If blnChar(intFile, "WPC", 1) Then
     If blnHex(intFile, "01", 8) Then
         If blnHex(intFile, "0A", 9) Then

That would suggest a means to specify a semi-colon list of (in this case) character strings at positions 1, 8 and 9.
This is not at all a priority for me; I am curious about how users might specify, for their own use, unique types of file.
Thanks, Chris

[void]

(1) Is this similar in manner to how you test for isJPG? I noticed a list of IS functions in this post.

Yes.

(2) Is there a possibility for the user to specify a type of file by searching the Content for such a string?

Yes, with the binary: search modifier.

For example:

ext:wpd wildcards:binary:content:?WPC????\x01\x0a*

Everything is smart enough to only read the first 10 bytes of the file, so this will be fast.

wildcards:
binary:



Alternative hex: search:
ext:wpd hex:startwith:content:FF5750431E000000010A

Again, only the first 10 bytes of the file are read, so this will be fast.

hex:
startwith: