Show the specified column, if path, name or full path and name is not specified, full path and name is used.
You can specify which columns you would like ES to display and in which order they are displayed

Export to a file.
Exporting as csv will export all specified columns.
Exporting as efu will export the filename, size, date modified, date created and attributes columns.
Exporting as txt will export only the filename column.
Exporting as m3u will export as ANSI play list.
Exporting as m3u8 will export as UTF-8 play list.

-csv
-efu
-txt
-m3u
-m3u8

Change display format.
Output can be redirected.

-size-format <format>

0=auto, 1=Bytes, 2=KB, 3=MB.

-pause, -more

Pause after each page of output.

-hide-empty-search-results

Hide results when no search is passed to ES.

-empty-search-help

Show the help when no search is passed to ES.

-timeout <milliseconds>

Timeout after the specified number of milliseconds to wait for the Everything database to load before sending a query.

-'s can be omitted, eg: instead of typing -no-digit-grouping you can type: -nodigitgrouping
Use double quotes to escape spaces and switches.
Use ^ to escape special command line characters, eg: escape | with ^|
Switches can also start with a / eg: /ad
Switches can be disabled by prefixing them with no-, eg: -no-size.
Highlighting is expensive, use as many search terms as possible or use -n to limit the number of results.

If the sort type is unknown, ES will now display an error message
Saving or clearing settings returns immediately, no search is performed.
There was some extra debugging information in 773b that would crash if there was no ES search results, was fixed in 782b.
You can use relative paths with -path <path>
The old -path command line option has been renamed to -path-column, so has -filename to -filename-column.
-pause will pause the display after each page.
dates are now displayed in the correct localized format.
added /ad /a-d command line options.

ES uses WriteConsole when connected to a console, for pipes ES uses WriteFile after converting to the consoles current code page.
No color information is passed to WriteFile.
Color information is only passed to WriteConsole.

Just for reference: chcp can be used to change the current code page of the command prompt.
To change to UTF-8, which maybe useful for piping data to other applications or to a file, use:
chcp 65001

The only Issue I am having is the line-wrap on long paths. I have been thinking about how to solve this issue, and the only format that I think would work if you can do it without too much trouble is. Again, if not doable, then no problem.

On paths that exceed available width, then replace the path name after three characters with "..." until the next "\". Depending on full length may need more than one substitution.

Thanks for the reply, I understand the issue, I'll experiment with ellipses.
If you didn't know you can use -name to show only the name part, but then of-course you lose the path information.
I'm finding I resize the console window so its slighter wider than 80 columns.

Yes I know of the -name option. Be sure to either get max columns or allow one to specify max width. My currently is set to 150.

Anther thought, there are so many options, that it takes some time to figure out the correct format. How about an optional configuration dialog box that allows one to select options. The box would have an option to run the search as selected to show output, and an option to either save in registry or to show the current command line option for current config to save as an alias or in a batch file.

If everything.exe is running as service, can the es.exe -instance parameter be used to specificy the everything.exe service to run or do I have to launch everything.exe UI? I'm trying to run this as a schedule task that is not visible to the user. If I run everything.exe using the -minimized option, the user sees the flashing everything.exe icon in the tray.

Also, is it possible for es.exe to search for multiple files\wildcards in the same search? would it be possible for es.exe to use a config.ini file for it's parameters like everything.exe does? Possible to list the files\wildcards to search for in that config.ini file?

Anther thought, there are so many options, that it takes some time to figure out the correct format. How about an optional configuration dialog box that allows one to select options. The box would have an option to run the search as selected to show output, and an option to either save in registry or to show the current command line option for current config to save as an alias or in a batch file.

More screenshots might help, I'll be making a Everything wiki page on ES soon..

can the es.exe -instance parameter be used to specificy the everything.exe service

No, ES communicates with the Everything search client.

If I run everything.exe using the -minimized option, the user sees the flashing everything.exe icon in the tray.

Also, is it possible for es.exe to search for multiple files\wildcards in the same search?

Yes:
es.exe *.jpg ^| *.png

would it be possible for es.exe to use a config.ini file for it's parameters like everything.exe does?

Instead of saving to the registry? I would have to put the es.ini in %APPDATA%\ES to avoid issues where ES doesn't have write permissions to the folder it is currently in. I could just make it a switch too: -save-ini, or -save-app-data-ini, es could try loading both on startup.

Possible to list the files\wildcards to search for in that config.ini file?

I wanted to avoid saving filters and searches in the settings as it's hard to figure out what es is searching for because they are not shown.

Thanks for the info. I can work w/ this but have one last question and then a possible bug report.

what is the maximum number of filename\wildcards that can be searched for at one time. Ex: *.jpg^|*.xls^|*.xlsx (that would be three, is there a limit to how many can be searched for at one time?)

I run everything -minimized, then when I search es.exe *.txt it shows results, but when I search es.exe *.txxt everything.exe crashes. It seems that if there are no search results everything.exe crashes.

I run everything -minimized, then when I search es.exe *.txt it shows results, but when I search es.exe *.txxt everything.exe crashes. It seems that if there are no search results everything.exe crashes.

what is the maximum number of filename\wildcards that can be searched for at one time. Ex: *.jpg^|*.xls^|*.xlsx (that would be three, is there a limit to how many can be searched for at one time?)

ES has a limit of 65535 search characters.
Other than that, there is no limit on how many search terms you have.

ext:jpg;xls;xlsx performance will be much much much greater than *.jpg^|*.xls^|*.xlsx when using multiple extensions.

I run everything -minimized, then when I search es.exe *.txt it shows results, but when I search es.exe *.txxt everything.exe crashes. It seems that if there are no search results everything.exe crashes.

There was some extra debugging information in 773b that would crash if there was no ES search results, was fixed in 782b.

782b should fix the issue.

RFE: If -pause, ESC or Q should exit the search.

(And maybe even some more more-like features, like CR to advance 1 line?)

Any reason for (more) exit codes?
I gather presently you can get a 0 or something not-0.

0 is fine (checking %errorlevel%), but maybe some other exit conditions could set other levels, that might be of benefit?
(And not that I'm thinking of any at the moment, as a 0-check so far has been sufficient.
I guess you could have something like:
0 success
1 success, no results returned
2 ESC from Pause
3 syntax error
XXX program break ...)

Currently there are 546 filename\wildcards in the list. I'm splitting the list and running it multiple times. everything.exe seems to crash w/ Everything IPS service not running when it hits this section of the filename\wildcards "RESTORE_FILES_*.txt^|RESTORE_FILES_*.*" if I remove those and run again, it chokes up on a similar combination. My guess is that it's because RESTORE_FILE_*.txt is also included in the RESTORE_FILES_*.* wildcard. Is there anyway to get it to skip duplicates instead of crashing?

I'm downloading this list of filename\wildcards from the web and it's updated often I'm trying to automate this so I don't have to manipulate the list manually.

i'm having issues w/ running everything.exe -startup and es.exe in a script.

I'd really like to not have to run it in a batch file, but launching everything.exe -startup doesn't seem to exit or send so the my scripting environment sits and waits for the everything.exe process to stop before it proceeds.

So if I run the filescan0.txt (rename to bat) its successful the majority of the time unless everything.exe takes too long to scan the drive on startup. If I add some extra filename\wildcards to the es.exe search as in filescan1.txt (rename to bat) it hangs almost everytime.

what I'd like to do is start everything.exe -startup w/ my scripting application, then return back to the scripting application to run es.exe w/ the various searches that I want to perform. Once I've completed all the searches then run everything.exe -exit. That way I don't have to launch everything multiple times and have to scan the drive each time it opens.

Is there an everything command line option I am missing to get this to work properly or is there a way the es.exe can call everything.exe if it's not running?

But I'm seeing something strange. I come up with this batch file which splits the files to check into multiple es.exe commands. All should find something because of the last wildcard and export the results to a txt file, but only filename1.txt contains anything. I'm echoing %errorlevel% and the errorlevel is always 0.

-pause/-more now shows a scrollable window, not sure if this is really an improvement, let me know what you think..
Q or Esc = Quit
Arrow Keys, Page Up, Page Down, Home and End = Scroll.
Enter = Scroll one line and exit on last line
Space = Scroll one page and exit on last page.

Default "prompt", ":".
If you want help, :h.
Save the stream to a file, :r c:\tmp\out.txt

Maybe a configurable prompt, so the "current" (bottom-most) line, total count of results.
[23/72]:

And at that point, you're much like Less.

I like it.
Certainly better.

If the number of returned results is the same as the window size (size-1), number of rows, its not quit obvious that there are no more results, so up/down, home/end... seem ineffectual. (Not a big deal, but.)

-pause does not allow LONG lines to wrap (or to scroll horizontally to the end).
-pause truncates long line output (to some extent, with viewport [window] width playing a factor, so if you resize, you may see more or less, but never in full).

The file is found, the line is displayed, but it is truncated.
It should be ~214 characters.
What actually ends up displaying may vary, perhaps between 92 & 136 characters (perhaps larger?), with the display width playing into what you get.

(In my case, I started the ES search from within the /ip19655837.ahodd.ini/ directory.)

-pause does not allow LONG lines to wrap (or to scroll horizontally to the end).
-pause truncates long line output (to some extent, with viewport [window] width playing a factor, so if you resize, you may see more or less, but never in full).

ES.exe has it's own, build-in, scrolling mechanism that is independent of the console host implementation.
Use cursor key right to see the missing part of the line. That should do the trick according to the -pause instructions at the bottom of your results:

ESC=Quit; Up,Down,Left,Right,Page Up,Page Down,Home,End=Scroll

BTW1: I usually resize the if I expect long lines (with WMIC, for example) :

That gives you a width of 300 characters and a height of 40.
Note that this is semi-independent of your "viewport"

BTW2: In this case your Windows (sub)version is relevant too. Recently Windows had some major changes (improvements in my opinion) in Console Host (conhost.exe is responsible for input/output to and from console applications like CMD.exe andnPowershell.exe)

Left Arrow Key / Right Arrow Key should scroll the view.
Do you see any scrolling? Does your console window have scroll bars?

ES -pause uses the current viewport rather than the size of the console.

So you might see this truncation when you have a console size of say 100x40, with a viewport of 80x40 (you should see a horizontal scroll bar at the bottom of the console window) If you use the scrollbar you will see that -pause only scrolls the initial viewport.

The ES method used to be about as fast as the GUI menu export back in November 2016. I've since then been using the ES method as part of some automatic backup scripts. I don't know at what version of ES/Everything the speed decreased.

Questions
- Can others reproduce that ES has gotten much slower at .efu export?
- Is there currently some command line method (with ES or Everything) to get the same data at the same speed as in the Everything GUI menu method from test 3? Assuming Everything is already running in the background on the system. Some option or parameter I'm missing? I did try the ES .csv export option with different settings but got similar results as in test 1.

Everything GUI is working from RAM, is not exporting all the detail that ES is.
ES is exporting detail that is not in RAM, not in .db, has to go to disk to gather those details.

As far as ES time, I'm seeing no difference between versions.
(There is a version from 2014, but it is far more basic, has no -export-efu...)
All later versions are running (the particular search I ran), on average, in .26 sec.

"Caching" can have a large impact on time. So if something "interferes" with what has been cached, results will be skewed.
(I'm not quite sure what I'm seeing in this regard. Sometimes extraneous activity affects things, sometimes killing a long running ES command followed by running the same again causes it to complete much quicker...)

There is another , important difference between the outputs: they are sorted different!
That means that ES.exe asks the GUI version (Everything search client) to produce all results from it's database. These results have to be sorted and "massaged". That takes quite some (CPU) effort and thus time.

To speed up the sorting, you normally use indexes. For this test I just enabled all indexes, including it's fast sort option (under Menu:Tools > Options > General). Feel free to research which index has the most influence on the speed (and please report the resulst here )

My guess is that ES.exe and Everything.exe are no longer "aligned" : ES.exe asks for layout 1; Everything.exe defaults to layout 2. Hence the extra time.

I don't know how you got different results running Ethe queries as a normal user vs running as an administrator (assuming you had the Everything service running). That should not be possible. Both talk to the (same) database, not the system.

EDIT: Upon rereading: This s not exactly what I wanted to say. (some reasoning is wrong). Will rewrite it later.

nod5 wrote:
Yes but using ES with the -sort-paths parameter (version of test 1) sorts the efu like in Everything exports (test 2/3). That parameter doesn't affect the speed of ES.

I was already aware of that (hence my "This s not exactly what I wanted to say. (some reasoning is wrong). Will rewrite it later."), but I was too tired to fix it at that moment. Sorry for confusion.

When I ran your ES quuery, it took 50+ seconds. All of that time CPU usage was somewhere between 60% and 70%. The only explanation I could come up with at that time was the sorting (as I said: very tired ..)

Now I think it is caused by all the extra info that isn't (by default) in the database, like attributes. Index those and you will get results much quicker.