Can't interrupt REGDIR
- Thread starter vefatica
- Start date
I just want to interrupt it, not make it pause ... you know, like DIR, PDIR, FFIND. It'd be useful especially considering that recursion is the default.
This command took quite a long time. I couldn't interrupt it. It seems to show a couple problems.
Code:
v:\> timer & regdir /v /d hklm | ffind /k /v /m /t"JPSoft" & timer
Timer 1 on: 13:52:05
PeriodShortcut : REG_DWORD : 1
Timer 1 off: 13:58:52 Elapsed: 0:06:47.0861. It didn't do what I asked it to do!
2. the time!!! ... the TCC running REGDIR showed 0 CPU for most of those 6+ minutes. In sharp contrast, my (ancient) REGFIND.EXE can go through HKLM, looking for "PeriodShortcut" (finding 536 of them) in about 11 seconds.
I'll experiment more.
Works fine here; returns only the keys / values with "Jpsoft" in them (several hundred of them).
I don't know why you would be trying that syntax - it's about the most inefficient way to search the registry imaginable. Most of the time is consumed by REGDIR formatting & outputing binary data that you don't even care about.
I have only 19 "jpsoft"s in HKLM (confirmed with REGEDIT). They're all found when I look in hklm\software\microsoft\windows. One instance of the wrong string is found when I look in hklm\software\microsoft (an enclosing key!). When I use GREP.EXE instead of FFIND, the correct strings are found in both cases.
You're probably right about the binary data. There are many REG_BINARY values (notably in HKLM\HARDWARE) with tens (maybe hundreds) of thousands of bytes of data.
What is a better way to search the registry for strings (in keys, values, and data) with TCC?
You're probably right about the binary data. There are many REG_BINARY values (notably in HKLM\HARDWARE) with tens (maybe hundreds) of thousands of bytes of data.
What is a better way to search the registry for strings (in keys, values, and data) with TCC?
Huh? You still get a 1-second per page delay. At that rate it would days to output all of HKLM.
One odd thing ... if I do
Code:
regdir /p1 /v /d hklm | grep .I don't get any delays and Ctrl-C stops both regdir and grep (and Esc does nothing). Whereas if I do
Code:
regdir /v /d hklm | grep .Ctrl-C stops grep and leaves regdir running.
Yup! The output of
Code:
regdir /v /d HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\DELL__\CBX3___\01072009has 862,000 characters. I reckon that accounts for over 280,000 bytes of data (all in one value).
And though I don't know what FINDSTR's limit is, when I pipe the output of "regdir /v /d hklm" to FINDSTR, I get "Line too long" 354 times
I did both REGDIRs ("microsoft" subkey and "microsoft\windows" subkey) sending the output to files instead of piping it to FFIND.
FFIND found the correct text in both files when NOT in a pipe (first two below) and failed (as described earlier) when in a pipe (second two below).
In a pipe, GREP gets it right in both cases. So does FINDSTR (with several "line too long" errors).
FFIND found the correct text in both files when NOT in a pipe (first two below) and failed (as described earlier) when in a pipe (second two below).
Code:
v:\> ffind /k /v /m /t"com.jpsoft" microsoft.key
C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
v:\> ffind /k /v /m /t"com.jpsoft" windows.key
C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
v:\> type microsoft.key | ffind /kmvt"com.jpsoft"
9:45
v:\> type windows.key | ffind /kmvt"com.jpsoft"
C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\In a pipe, GREP gets it right in both cases. So does FINDSTR (with several "line too long" errors).
TCC doesn't have a built-in way to search the registry, because (1) there's a zillion other tools out there to do it, and (2) nobody ever asked for it.
Personally, I just use REGEDIT.
In a pipe, FFIND seems to fail beyond some point.
"D4373260-1185-49AC-993B-A31209FBD6CC" appears near the end of "DIR /s c:\" (~64MB output). And I see this (first line of output is fishy):
"D4373260-1185-49AC-993B-A31209FBD6CC" appears near the end of "DIR /s c:\" (~64MB output). And I see this (first line of output is fishy):
Code:
v:\> dir /s c:\ | ffind /vkmt"D4373260-1185-49AC-993B-A31209FBD6CC"
latedpackages-package~31bf3856ad364e35~amd64~pt-pt~10.0.18362.476.mum
Directory of C:\Windows\{D4373260-1185-49AC-993B-A31209FBD6CC}\*
Total for: C:\Windows\{D4373260-1185-49AC-993B-A31209FBD6CC}\I created a big (88,888,897 bytes) file like this ... while I was having dinner ... it took a while.
FFIND worked well (and quite fast) when not in a pipe. This is correct and took less than 4 seconds.
... not so when in a pipe. This is wrong and took 44 seconds.
Code:
(do i=1 to 10000000 ( echo %i )) > reallybigfile.txtFFIND worked well (and quite fast) when not in a pipe. This is correct and took less than 4 seconds.
Code:
v:\> ffind /mkvt"123456" reallybigfile.txt
123456
1123456
1234560
1234561
1234562
1234563
1234564
1234565
1234566
1234567
1234568
1234569
2123456
3123456
4123456
5123456
6123456
7123456
8123456
9123456... not so when in a pipe. This is wrong and took 44 seconds.
Code:
v:\> type reallybigfile.txt | ffind /mkvt"123456"
123456
1557
3123456
987591
6123456
987591
9123456Similar threads
