How to? %@everything[] question

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
TCC 20.00.14 x64 Windows 10 [Version 6.3.14393]
TCC Build 14 Windows 10 Build 14393


Here's the @everything[] example shown in the v.20 online help:

echo %@everything[tcc.exe,f]

On my system, the above returns three or four "hits." Then this command:

echo %@everything[tcc.exe,f,1]

... returns only a single "hit" — the very first one shown when parameter "1" is not used.

Different kind of results with wildcards, though.

echo %@everything[*8*.tmp,f]

... returns around 85 "hits" to the console. But an attempt to get only one match by using the optional numeric parameter fails:

echo %@everything[*8*.tmp,f,1]

... returns "Echo is OFF".

Shouldn't this last example return the first "hit" that's displayed when the parameter "1" has not been used?


This, however, does work — note that there's an additional character in the file spec:

%@everything[*b8*.tmp,f,1]

It returns the fully-qualified name of a single file on this system matching "*b8*.tmp".

Why did it fail for "*8*.tmp" when both "f" and "1" params were used?
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#2
This is an internal Everything bug/feature; there's not anything I can do about it.

The problem is because Everything is returning 1 match (as requested). But when you provide a count, it's ignoring the directory / file specifier, and the first match returned happens to be a directory, not a file. So nothing is displayed.
 
#3
The EVERYTHING command exhibits similar behavior, but a well-constructed search string gets around the difficulty.
Code:
h:\work> d w*
2016-08-21  00:17  <DIR>  words
2015-02-08  16:06  393  w32h.btm
2014-09-30  23:37  2,320  w32tmparams.btm
2014-10-01  00:17  1,924  w32tmparams17.btm
2015-08-06  11:50  1,791  w32tmparamsx.btm
2016-06-18  12:26  53  who.txt

h:\work> everything /f /m=1 "h:\Work\w*"

h:\work> everything /m=1 "file: h:\Work\w*"
H:\work\w32h.btm

h:\work>
I can't figure out how to do that with @EVERYTHING.
 
#5
To try another few examples to see what would and wouldn't work, I ran a few "everything" or "echo %@everything[whatever]" commands only to find it not working again. No results returned in any case.

Thinking back on a thread of a day or so ago I ran "Everything /o", then clicked Apply without changing anything in the dialog, then returned to the command prompt. The Everything commands began working again.

Is this the drill, then — after each reboot, before Everything will work at all, you have to run Everything /o? once?
 
#6
To try another few examples to see what would and wouldn't work, I ran a few "everything" or "echo %@everything[whatever]" commands only to find it not working again. No results returned in any case.

Thinking back on a thread of a day or so ago I ran "Everything /o", then clicked Apply without changing anything in the dialog, then returned to the command prompt. The Everything commands began working again.

Is this the drill, then — after each reboot, before Everything will work at all, you have to run Everything /o? once?
It sounds as if you're not running Everything at startup. Go into Everything's options and select "Run Everything at startup" in the General tab. You should also make sure that "Run as Administrator" is NOT selected to avoid getting a UAC prompt every time you log in.

-- Howard
 
Likes: mikea
#8
I believe it works something like this. In order to monitor file system changes, you need EITHER the Everything service OR an elevated instance. There is no reason for both. If you run the service, TCC cannot communicate with it, so a "client server" (unelevated instance) is also needed.
If you don't run the service, but start an elevated instance of "everything.exe -startup", that's all that's needed. Note that this second mode of operation was not available in older versions of Everything; in particular, it was not available with the Everything.exe from TCv18.

You can avoid the UAC prompt with a scheduled task: "[path\]everything.exe -startup" ... run with highest privileges ... triggered by your logon. I just tested that on Windows 7.
 
#9
For starters I took the simple way out: run Everything /o and select the start-with-Windows option. That also seems to have selected starting the service and running as administrator. During the next boot, when the UAC dialog appeared for Everything, it didn't display Everything's name in the dialog box, but TCC 20's name. (This is under Win 10, if it matters.)