DIR command combo that hangs with high CPU %

[IMustBeStupid]

I have a command I try to use on occasion when I want to search for text globally on disk (usually from the C:\ directory):

ffind/s/v/t"amazing" *.*|list/s

(replace 'amazing' with the text to search for)

TCC never completes this command (I've let it run for days on end) and task manager shows TCC with high (30-100%) CPU utilization. If I do the same command without the list/s at the end it completes within a short time. In that case however, if the text is found in binary files I often get a lot of beeps from embedded bell characters being 'displayed'. Also, sometimes there is so much text produced it overflows the scrollback buffer and I am unable to see all matches. Thus the list/s to capture it into a scrollable screen.

I know there are other ways of accomplishing what I want, but it would be nice if this command combination worked as expected.

TCC 12.10.58 x64 Windows 7 [Version 6.1.7601]
TCC Build 58 Windows 7 Build 7601 Service Pack 1
Windows 7 Home Premium x64 Athlon II x2 8Gb RAM
(Although I've had the same results on all versions TCC (9.x-12.x) and all versions of Windows 7 I've tried, and IIRC Windows XP had this problem too)

 

[Charles Dye]

That command works fine here, grovelling through 74 gigs in under three minutes. (Window XP, 32-bit.)

Do you have an alias for LIST? What's in your TCSTART file?

 

[IMustBeStupid]

That command works fine here, grovelling through 74 gigs in under three minutes. (Window XP, 32-bit.)

Do you have an alias for LIST? What's in your TCSTART file?

No alias for list.

TCSTART contains:
prompt $t $+$P$g
shralias
alias /r "%@Path[%comspec]aliases"

Perhaps something in TCMD.INI? I've attached a copy...

 

[Steve Fabian]

The first command in TCSTART ought to be something like this:

if %_pipe EQ 1 quit

because a piped-to session already inherits the whole environment (variables including PROMPT and PATH, functions, aliases, etc.), so most of that work is superfluous. Regardless, it is still short enough (though requiring at least one disk access) that it could not account for all of the processor time it accumulates.

I'd suggest you try the in-process pipe "|!" - it puts the result of the command on the left into a temporary file, which is then used as the input of the command on the right.

 

[Charles Dye]

I don't see anything that would cause that behavior. What's in your ALIASES file? Do you have the same issue if you pipe to something else, like MORE?

 

[rconn]

I have a command I try to use on occasion when I want to search for text globally on disk (usually from the C:\ directory):

ffind/s/v/t"amazing" *.*|list/s

(replace 'amazing' with the text to search for)

TCC never completes this command (I've let it run for days on end) and task manager shows TCC with high (30-100%) CPU utilization.

Not reproducible here (it searches my D: drive with 447Gb in files in about 4 minutes).

Try it with the /NJ switch as well -- you might have a circular junction / symlink. (If you're running Windows 7 and doing this on your C: drive, you definitely have circular junctions, because that's how Windows 7 is configured by default!)

 

[IMustBeStupid]

Not reproducible here (it searches my D: drive with 447Gb in files in about 4 minutes).

Try it with the /NJ switch as well -- you might have a circular junction / symlink. (If you're running Windows 7 and doing this on your C: drive, you definitely have circular junctions, because that's how Windows 7 is configured by default!)

Sorry for the delay in responding. Been distracted with other things.

Thanks for all of the suggestions, but none of them have resolved the problem: /NJ, |!, redirect to a file, pipe to MORE, all hang. Past experience tells me Murphy is behind it... I seem to have all kinds of strange problems no one else encounters, with all kinds of tools. I guess I should just feel special and move on...

 

[Charles G]

Just off the top of my head - would a disk check and maybe a defrag help matters here?

 

[IMustBeStupid]

Just off the top of my head - would a disk check and maybe a defrag help matters here?

Defrag regularly, haven't done a chkdsk lately but I have had this problem consistently for a long time and have tried it on other Win7 machines, seeing the same problem.

Might be an interaction with some of my other software... I guess I could spin up a clean Win7 VM and try it there... But I have another grep tool I can use, so the time consumed on this issue is crossing the "worth it" threshold.