Is there a simple solution for Voidtools Everything search from within AHK? Topic is solved

Get help with using AutoHotkey and its commands and hotkeys
simpleeverything

Is there a simple solution for Voidtools Everything search from within AHK?

29 Nov 2016, 16:48

As you know, you can do file name search over your whole system by "Everything" (Voidtools), and you can AHK have fill in the fields in the Everything GUI; by control-c, you then can import the search results into the clipboard, and then process them, all in AHK; visually, this is catastrophical.

I have seen AHK-"Everything" scripts with hundreds of lines; the "Everything" site gives a (not-so-bombastic) "C" example; I don't "speak" "C", so that doesn't help me. So I'm looking out for something intermediate which I could understand.

"Everything" has a command-line add-on (I say add-on since the main program must be present, too), and it is said that you can run searches, e.g. from within AHK, in the form of

Code: Select all

run, c:\programfolder\Everything\es.exe searchstring optionaloptions Enter
This opens a DOS window (or rather that thing that mimics a DOS window in Windows today), but:

1) It closes immediately (do not do "run, es.exe" without a search string since then the DOS window will run "forever" instead); if I open a DOS window, then run es, es opens a SECOND DOS window which closes immediately; putting a "/K" or something behind the run command does not help: a second script line "pause" will even pause your AHK script, not retain the DOS window. And yes, since the DOS window is an optical nuisance anyway, I would even be happy to have it disappear immediately "in production runs", as it does now (once I get the results that is!), but doing it now, it prevents me from reading any possible error messages,

2) I don't have the slightest idea how to get the result data out from that faux "DOS" window, ideally directly into a variable, or at least into the clipboard, so that then AHK could access the results there.

There is not much help from Voidtools, the link https://www.voidtools.com/support/every ... e_options/ for example mentions "Command line options to manipulate the search", such as "Enable or disable case matching." or "Command line options to manipulate the search window and results", with "Sort ascending" for example, but does not say how to fetch the results in the first place.

I'm aware that my (implicit) questions are not really AHK-specific, but either "Everything"-specific or with regards to running command-line programs, from AHK, in general, but since the very last aspect is of general interest, and "Everything" expert knowledge is obviously available in this forum, judging from those brilliant scripts that are beyond my understanding, I try my chance here.

Ideally, somebody even knows a rather short, "evident" AHK script, with just so few DLL calls or such, for entering the search, and then for retrieving the results (and which would thus spare me the DOS window)?
Fee
Posts: 57
Joined: 05 Aug 2016, 14:30

Re: Is there a simple solution for Voidtools Everything search from within AHK?

29 Nov 2016, 17:34

https://autohotkey.com/docs/Variables.htm#ComSpec
http://ss64.com/nt/clip.html

Code: Select all

InputBox,searchstring,es.exe search, What to search for:
RunWait, % comspec " /c c:\programfolder\Everything\es.exe " searchstring " | clip",,hide
MsgBox % "Results copied to clipboard"
MsgBox % clipboard
Guest22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

29 Nov 2016, 20:20

Thank you very much for your kind help, Fee.
Unfortunately, I do not grasp the syntax of the command line.
Your simplified code

Code: Select all

RunWait, % comspec " /c c:\programfolder\Everything\es.exe " searchstring " | clip",,hide
MsgBox % clipboard
does not give an error message, but just displays the previous (and thus not replaced) clipboard content.

It seems your code is this:
RunWait, % comspec XXX,,hide ; AHK command incl. comspec as variable to retrieve the search results, thru cmd.exe,
; if I leave the "hide" out, I see the cmd.exe window (quickly disappearing); XXX is sent to the system:

" /c c:\programfolder\Everything\es.exe " searchstring " | clip"

is the part sent to the system:

space /c c:\programfolder\Everything\es.exe space ; why the spaces? but when I leave them out, I get an error message;
; why the /c ? It's not mentioned in the "Everything" help file it seems ( nothing in https://www.voidtools.com/support/every ... interface/ about it), but when I leave it out, I get an error message, here again

space and searchstring and space ; the searchstring without double quotes, but adding them does not harm (no result, but no error message either)

" | clip" ; clip being the copy command, or the "redirect", which I now know by your kind help.

But then, I do not get any search result into the clipboard, trying, among other things, as searchstring autoexec, in order to get c:\autoexec.bat as result, at the very least.

I'm very sorry that any such very kind help triggers more needs, but perhaps if you could tell where's the string from you send to the system, I could find out why your code does not work yet for me.

_______________

I had another look at the "C" example given by "Everything"'s developer: https://www.voidtools.com/support/every ... c_example/

As said, I cannot analyze that code, not knowing "C", but it's quite simple, whereas AHK scripts come with 500 lines and more, and with "IPC", i.e. without going thru a command window (even invisible now), it seems Everything allows a lot more, in terms of search commands/options. Thus, it would probably be a very good idea to translate David's C code almost 1:1 into AHK, which would perhaps give 80 or 100 lines instead of around 40, but which would be of perfect clarity. This being said, I'd be probably very happy with Fee's 1-line code, once it'll work, and if search options are not too reduced by "going command window" instead of IPC; cannot try those but when the code'll be working!

_______________

Btw, in the web you'll find contradictory info about if the main program "Everything" must be running at the same time, or must be closed (but be present on your pc) at the same time you invoke the es.exe; I tried both alternatives, with the same, no-, result.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 01:27

Guest22 wrote: I had another look at the "C" example given by "Everything"'s developer: https://www.voidtools.com/support/every ... c_example/
Did you look at the other C example given: https://www.voidtools.com/support/everything/sdk/c/

If you drop Everything32.dll/Everything64.dll from the SDK zip into the same folder as this AHK script, this is all you have to do:

Code: Select all

EverythingDll := "Everything" . (A_PtrSize == 8 ? "64" : "32") . ".dll"
EverythingMod := DllCall("LoadLibrary", "Str", A_ScriptDir . "\" . EverythingDll, "Ptr")
DllCall(EverythingDll . "\Everything_SetSearch", "Str", "autoexec")
DllCall(EverythingDll . "\Everything_Query", "Int", True)
Loop % DllCall(EverythingDll . "\Everything_GetNumResults", "UInt")
	MsgBox % DllCall(EverythingDll . "\Everything_GetResultFileName", "UInt", A_Index - 1, "Str") . " [" . DllCall(EverythingDll . "\Everything_GetResultPath", "UInt", A_Index - 1, "Str") . "]"
DllCall(EverythingDll . "\Everything_Reset")
DllCall("FreeLibrary", "Ptr", EverythingMod)
guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 05:55

@ Fee

I'm sorry for having introduced unnecessary mistakes into this problem last night, it had been almost 3 o'clock in the morning for me. Of course "searchSTRING" is a variable, not a string, coming from the original inputbox, and in fact, I first had done, without success, and again this morning to check, and with the same result:

Code: Select all

clipboard =
searchvar := "autoexec"

; runwait, %comspec% " /c c:\Programme\Everything\es.exe searchvar | clip",,hide
; msgbox, %comspec%

runwait, % comspec " /c c:\Programme\Everything\es.exe searchvar | clip",,hide
msgbox % comspec ; instead, it always gives the string: C:\WINDOWS\system32\cmd.exe (and not its contents)
Thus, I was right that your code (which for the reasons given above I don't understand) you were so kind to give to me, did and does not work on my system (my tiredness then mixed it all up AFTER this "correct" code not working), but I hope you''ll look into it again this evening.
_______________

@ querty12

Thank you so much for your kind hint. I'll look into that and will report!
Guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 06:13

@ Fee

Correction:

Me wrong again, your code was

Code: Select all

runwait, % comspec " /c c:\Programme\Everything\es.exe " searchvar " | clip",,hide
; not runwait, %comspec% " /c c:\Programme\Everything\es.exe searchvar | clip",,hide
and I had used your code last night, but with the result given before. Btw, including searchvar in %% does not change that result.

I suppose your leading /c is an "acceptable" option for the system (no error message), but not one "Everything" understands.
Fee
Posts: 57
Joined: 05 Aug 2016, 14:30

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 06:56

comspec is built-in variable that contains path to your systems cmd.exe.
So following lines are pretty much equivalent:

Code: Select all

Run, C:\Windows\system32\cmd.exe ; depends on your system
Run, cmd.exe
Run, %comspec%
Run, % comspec
and MsgBox % comspec just shows path to cmd.exe

Code: Select all

searchvar:="autoexec"
Run, % comspec " c:\programfolder\Everything\es.exe " searchvar
Is equivalent to opening cmd.exe and there typing:

Code: Select all

c:\programfolder\Everything\es.exe autoexec
which should give you results displayed in console.
What we do here:

Code: Select all

searchvar:="autoexec"
RunWait, % comspec " /c c:\programfolder\Everything\es.exe " searchvar " | clip"
is using | (pipe) to redirect output from console to clipboard.
http://ss64.com/nt/syntax-redirection.html
http://ss64.com/nt/clip.html
Since you said clipboard is not ideal you can instead redirect output to file,read the file >delete the file:

Code: Select all

output_path:=a_scriptdir "\es_output_temp.txt"
FileDelete,% output_path
searchvar:="autoexec"
RunWait, % comspec " /c c:\Programme\Everything\es.exe """ searchvar """ > """ output_path "",,hide
FileRead,output,% output_path
MsgBox % output
The mess with double and triple double-quotes "" """ is required to handle the way spaces are treated by cmd.exe
http://ss64.com/nt/cmd.html
/c is a switch for your windows cmd.exe (command prompt) NOT for es.exe (everything app).
/C Run Command and then terminate

clip once again is cmd.exe and not es.exe related.
http://ss64.com/nt/clip.html
guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 08:54

@ Guest

Thank you for the link, I've had a look into it and admit it's very clearly commented and, as such, "accessible", and thus could be a realistic approach to do an individual adaptation. But I have a mix of questions/considerations:

First: What about speed and robustness, etc.? Voidtools "Everything" has got a name that almost defies googling it, the name put naked into the search field at least, but is an incredibly stable and mature software with which all sorts of very complicated searches (i.e. searches that do their best to reduce otherwise "endless" hit tables), incl. regex and all sorts of in- and exclusions, just by varying the search string (the only problem being that "you" never remember the needed search string combination if you do not need those on a regular basis); I suppose the corresponding AHK script (which also accesses the MFT table for speed) is not (i.e. cannot be) as elaborate as the powerful Voidtools query tool, and what about index building in the AHK script, when in "Everything" even that problem is resolved in a way you cannot probably do any better?

Second, and implicit above, "you" would probably need to write lots of additional code to bring it even near the powerfulness of "Everything", since in AHK, some functionality is not implemented yet. For example, regex is possible for window identification, but not in file loops, so I had to write recursive functions for doing "elaborate" file identification (which work well, thanks to the incredible help got here), in order to have the script decide correctly if a given file is to be included into the list it's building up or not, instead of just doing a (in direct comparison incredibly simple) regex "include it: yes/no code line". (I do file naming / "tagging" by "hierarchical" strings at the beginning of my main files, in my main directory, and then identically-named subfolders for "normally"-named "secondary" and "tertiary" files, so regex in file loops would be very welcome, but I can apply now recursion instead, I'm not complaining.)

Thus, I fear that the AHK-all solution, as it is at least, would give lesser results; this being said just by very quickly browsing the code, so my assumption may be very injust.

_______________

@ Fee

Thank you very much for your kind explanations; in fact, from your link, I hadn't grasped comspec already. I know the concept of redirection, and I also know that double quotes must be escaped by double quotes, but have got quite some difficulties with those cases in real life, lots of fumbling and trial-and-error.

I happily confirm that your new script works fine (correct hit table in the msgbox), but your previous code persists in NOT working, my scrutinizing it again and again doing no help. Here are both again, with my paths:

Code: Select all

/*

; works fine, redirection into the file, then the list in msgbox:
output_path:=a_scriptdir "\es_output_temp.txt"
FileDelete,% output_path

searchvar:="autoexec"
RunWait, % comspec " /c c:\Programme\Everything\es.exe """ searchvar """ > """ output_path "",,hide
FileRead,output,% output_path
MsgBox % output
*/

; redirection does NOT work, additional double quotes do not seem to help (of course, I may have left out the precise variant that would have worked):
searchvar := "autoexec"
RunWait, % comspec " /c c:\Programme\Everything\es.exe " searchvar " | clip",,hide
MsgBox % clipboard
And in spite of the brilliant solution below, giving me the full power of "Everything", I continue being very interested in the solution of this mystery, since it's obviously of importance for other such program calls, too.
_______________

@ querty:

Absolutely incredible help, thank you a thousand times! (Well, to be honest, I would have said that to Fee already and instead, had his codeline done the wanted redirect and thus you had probably not stepped in. I have not digged into it, but, as said, strongly believe that the IPC your solution gives me now access too, allows for realizing much more powerful searches than the command-window solution, with its probably sub-set-only search facilities (which I deduct from the above-linked help page, listing what seems to be a subset only).)

Thus, to put this straight for other NON-programmers, what's to do to make your brilliant solution work (and I've got one question, too):

Code: Select all

; I unzipped the SDK, then put a copy of the (in my case) Everything32.dll into my AHK folder, now with:
C:\Programme\AHK\Everything32.dll

; _______________

; from the key assignments in my only and main script C:\Programme\AHK\1.ahk :
$!F9::
	searchby_voidtools_everything()
	return	

; _______________

; your fantastic script as a function in the regular (i.e. non-autoexecute) section of my main (and unique) script
; c:\AHK\ahk.exe, with my adaptation (inputbox for search, and all results listed in ONE var):
searchby_voidtools_everything()
{ ; begin of function : these indicators, also with outer loops, etc., spare me too much indentation (overflowing lines)

inputbox, eingabe, Search by Voidtools Everything :,,, 300, 120
if eingabe = ; German for "input"; I try to avoid English var names that could probably be or become program invariants or such
	exit

resultlist = ; initialization not needed, just for clarity

EverythingDll := "Everything" . (A_PtrSize == 8 ? "64" : "32") . ".dll"
EverythingMod := DllCall("LoadLibrary", "Str", A_ScriptDir . "\" . EverythingDll, "Ptr")
DllCall(EverythingDll . "\Everything_SetSearch", "Str", eingabe) ; changed to searchvar "eingabe"
DllCall(EverythingDll . "\Everything_Query", "Int", True)

Loop % DllCall(EverythingDll . "\Everything_GetNumResults", "UInt")
	; just replaced: _MsgBox %_ (which gives the hits one by one) by: _resultlist .= "`n" ._ :
	resultlist .= "`n" . DllCall(EverythingDll . "\Everything_GetResultFileName", "UInt", A_Index - 1, "Str") . " [" . DllCall(EverythingDll . "\Everything_GetResultPath", "UInt", A_Index - 1, "Str") . "]"

DllCall(EverythingDll . "\Everything_Reset")
DllCall("FreeLibrary", "Ptr", EverythingMod)
stringtrimleft, resultlist, resultlist, 1 ; the very first "`n"
msgbox, % resultlist ; gives hit list, in the form delivered by your script (will try to adapt to my specific needs)
; or then, return, resultlist in order to process it further

} ; end of function
My question being, you do a loop of subsequent dllcalls which (the dllcalls) give the results one-by-one, and I build up the full list ("hit table") within the loop. Did you do that in order to show me the results one-by-one, or is this necessary here? I'm asking since Free's (second, correctly-redirecting) script comes without a loop; this being said, it's also obvious that there, all the work is done behind the scenes, so your loop is probably necessary and just shows WHAT's done behind the scenes in the cmd.exe solution.
guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 09:09

Correction

Very sorry, my only ahk script is "c:\Programme\AHK\1.ahk" (there is no additional one "c:\Programme\AHK\ahk.exe"; I had written that from (wrong) "memory", then missed to correct my mistake). Key assignment and function are both in the non-autoexec section of "c:\Programme\AHK\1.ahk", the script I run upon Windows start.
qwerty12
Posts: 468
Joined: 04 Mar 2016, 04:33
GitHub: qwerty12

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 10:09

Hi, no problem,
guest 22 wrote:allows for realizing much more powerful searches than the command-window solution, with its probably sub-set-only search facilities (which I deduct from the above-linked help page, listing what seems to be a subset only).)
To be fair, Fee's solution is far easier to manipulate - adding the regex flag for example is a matter of just specifying the switch. With this, you have to know to DllCall EverythingSetRegex (which would be DllCall(EverythingDll . "\Everything_SetRegex", "Int", True)) (and the same with Everything_SetMatchCase - the function, aside from the name and the end result, matches in every other way)
My question being, you do a loop of subsequent dllcalls which (the dllcalls) give the results one-by-one, and I build up the full list ("hit table") within the loop. Did you do that in order to show me the results one-by-one, or is this necessary here? I'm asking since Free's (second, correctly-redirecting) script comes without a loop; this being said, it's also obvious that there, all the work is done behind the scenes, so your loop is probably necessary and just shows WHAT's done behind the scenes in the cmd.exe solution.
If you look at the page I got the code, you'll notice that it's pretty much the same as the AHK code, except I make allowances for the fact that, well, we're using AutoHotkey and all that entails. As far as I know, the Everything SDK doesn't allow the results to be returned as one string. As you noted, es.exe most likely gets the results back one by one, just as with our usage of the SDK; with Fee's solution, the results would only be one string because the processing has already been done by es.exe.

@Guest

Thanks for the link (and to wOxxOm for the code)! I knew there was the open source SwiftSearch out there, which also queried the MFT and I wouldn't be able to understand, but it's awesome to see someone had done it natively for AHK!
guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?

30 Nov 2016, 14:01

Thank you so much again, querty12.

I'll look into the SDK now, in order to verify if it can do "something more" of practical value for me, as I (perhaps erroneously) assume; after all, there should be good reason for its existence, with es.exe being there, too.

And I seem to have been right about "es.exe by cmd.exe": Seems you cannot do searches but the most basic ones, or that then you must use the commands in the es.exe help file / command lists: even a simple searchvar := "abc c:\somefoldername" (but which is more than a very basic "abc", which is processed correctly) brings an empty result, while the IPC works fine for composite search strings. (Inadvertantly, I used a regex with the IPC regular (not-regex) dll, and the whole AHK script crashed immediately, but no further harm done, and "result" finally as had to be expected!)

Btw, very long lists (which are thus to be avoided in the first place) took many seconds to be built up, with no sensible time difference between es.exe and IPC, so it seems indeed both fetch the results one-by-one, then build the list. I had hoped for a time difference at the advantage of es.exe, in order to justify its use, but there is none: search "d:\somefolder" with more than 200.000 results: es.exe 73 seconds (it's an old computer), IPC 69 seconds... but: if you do the same search in the "Everything" GUI search line, then do a tab to go to the search result list pane, then press the "end" key, the whole list is displayed instantly, so both es.exe and IPC take an incredible time to build up a SECOND list, from an internal one which is already there: I use the IPC now for lists of some dozen or some hundred entries, so the results are instantaneous, but for other uses I think mentioning my observation is worthwile).

As I see it now, from only so much trial, the cmd / es.exe solution only accepts the most basic search strings, or then more complicated ones by proper use of the options, etc., whilst the IPC solution also accepts (i.e. brings real (not just empty) results for) more complicated ones, without the need to memorize se.exe-specific options which are neither compatible with "Everything" GUI nor with its IPC (which is mostly identical with the "Everything" GUI searchline, except for regex and possibly other exceptions (I must check the dll's)), so from my current point of view, es.exe does not bring any advantage, especially since there is no time advantage and it's not possible to enter a "normal" elaborate search string, as you would with the "Everything" GUI and, to a certain extent, with the IPC, so I stay with IPC-regular and IPC-regex, probably with the same command (my scriptlet would analyze "eingabe" (input) of the inputbox ( if instr(eingabe, "regex")), then delete the "regex" substring and call the regex dll instead of the regular one.

_______________

Digression

I would like to shortly describe why I consider "Everything", especially in the elegant form of an AHK-result-list-for-further-processing, without any more fuss / interaction with an unwanted GUI / form, made so kindly available by Fee and, even more so, querty12, so incredibly useful; in fact, its usefulness goes far beyond identification of "lost" files, i.e. files inadvertently stored "anywhere" instead of in their proper (sub)folder). ("Everything" is NTFS-only, but I'm fine with that, and you can reformat usb sticks with ntfs, and as for web storage, well, you could at least have IPC-produced "snapshots" there, by storing the AHK result lists, and that's exactly what you would get from the usual file managers, whilst when in your office or your home, with IPC-and-AHK, these would be regularly updated and would become "live stuff".

As we all know, some dedicated file managers come with "Collections", "File Containers", storable "Scrap Panes", "Paper Folders" and probably others, all these "virtual folders" being in fact path entries (links) in XML files or simple lists (in ini files, the registry or such) which are NOT updated (yet) upon renaming, moving or deleting the original file (broken links), in these programs and as far as I know (I checked but not currently).

Btw, at least in the fora of DO and XY, there are (proprietary) scripts how to "integrate" "Everything" search result lists into panes of these programs, and this is not astonishing, since if the "search" is only fast enough (a feature that only searchers with MFT table use and/or such with (heavy, up-to-date) indexing provide), "LIVE" "collections" are so much better, i.e. "virtual folders" built up by stored (!!!) searches (some of the aforementioned file managers offer stored searches, but I don't know how the latter integrate with the "Everything" search from within there):

Not only the problem of updating after rename / move / deletion (which becomes really almost unmanageable once these are done with another (!) file manager than the one that stored it into one of its "collections") is resolved (I admit that both rename and deletion could make an adjustment of the stored-search search string necessary, in case, but, for exemple, not simple file name renames if the rename doesn't affect the coded part of the filename ("tag")),

BUT, with proper "name coding" / "tagging", AND proper choice / construction of the stored searches (regex), you can, this way, even include NEW files and file groups into a given search = "collection" / "virtual folder", to be created only in the future, instead of having to include these then one by one, or, worse and more realistically, do NOT include new files into these, simply but not thinking of that upon creation time, a problem worsened whenever you have certain files in more than one "virtual folder" and would like to have new, similar files also there, in which their alike-ones are already listed:

With the aforementioned "list" solutions, this is almost impossible or at least extremely cumbersome, whilst good planning of file name encoding / "tagging" PLUS foresightful planning of the stored "live" searches (i.e. re-build of the "collection" every time you trigger the search again) works wonders here.

And, with such a naming system...

(which as said, for the less important and/or less-often accessed files, comprises the folder names instead of the file names (too much fuss for "nothing"), but which of course complicates the search-string building; and indeed, I plan to process "Everything"'s search result lists according to main files vs. files in homonymously-named / coded / tagged folders, separating the results into different variables / lists then, i.e. not displaying all results up-front, but have subgroups stored in variables from which then I can have them flow in (sub-) panes, only when needed, so this is far beyond the possibilities of traditional file managers, except for heavy, proprietary scripting within them perhaps),

...the creation of new files becomes much easier, since you do not need to switch to the "right" file system folder first, upon creation of the file (often under time pressure) but just need to give an "approximated" tag to it and be sure to find it anyway within the context you'll need it again (for example, if you don't remember the exact tag "nbc" upon creation, you'll remember, and code, the "parent code" "nb" though, and your stored search for "nbc" includes "nb" (which ideally would be empty, so will never grow too much, the "real" "nb" stuff being in "nbg" for "general", or in my case "nba" for "Allgemeines") will bring about that "nbc" hit which is just in "nb" (and in whichever folder), and now, with some leisure time and "within context", you can rename the code from "nb" to the correct "nbc" and even move the file into the "correct" "nbc" folder (command: "filemove current list entry to current target directory") if that's important psychologically for you; technically, it's not, anymore.

_______________

Thank you so much again, Fee (the cmd.exe solution is obviously "lesser", but that's not your fault!), and querty12 (your solution is near ideal), and I would never have been able to find out any of these solutions, which make it all possible, by myself: just great!
guest 22

Re: Is there a simple solution for Voidtools Everything search from within AHK?  Topic is solved

30 Nov 2016, 14:43

Correction

After posting, it occurred to me that I may have discarded es.exe too hastily. I had (implicitely) said that cmd.exe did not accept search strings with spaces in them, so I remembered the old "double quotes" problem and tried again, and yes, if you search by es.exe, you should include your search string by three double quotes at either end (i.e. 6 double quotes in total): for simple search string, they at least do no harm (unexpectedly, I'm surprised!), and for composite search strings they are absolutely needed.

So es.exe and IPC are on par again. (Just with the difference that with es.exe, for special things, you have special options, and with IPC, you call special dll's.)

Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], DarkKitten, Google [Bot], Gully, MrGrayline, nacken012, rtepub and 70 guests