Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Can FFIND match file names with a regular expression?

Aug
149
4
The ability to use a regular expression to search through the text in files with FFIND is great, but I often find myself wanting to search file names, not their content, on the basis of a regular expression instead. Is there any way to do that with FFIND? Or is there another TakeCommand command that might do that? If not, how about considering it as a feature request? Thanks in advance for any information.
 
You know, it's amazing to me how even after using Take Command for years (and 4NT, 4DOS, etc. long before that), I still keep finding out about entire sets of features I knew nothing about. So first, thanks for the overdue schooling. Second, I'm having a couple of problems with using regular expressions:
  1. When I use the command "FFIND /s ::.+-Help\.xml", I would expect it to find any files whose names end with "-Help.xml" but it finds nothing. Interestingly enough, I can use "FFIND /s ::-Help\.xml$" to find exactly the files I seek. I get why the latter works, but I don't understand why the former fails. Do you?
  2. I'm so used to using FFIND that it never occurred to me to use the "simple" DIR command to search for files (dumb, I know), but when I use the command "DIR /s ::-Help\.xml$" it lists a few files and then crashes Take Command completely.
All of the searches I'm using for sake of example are being conducted from the C:\Windows folder of a Windows 7 x64-bit installation. The problems I mention are repeatable by me; can you comment on them? Thanks in advance!
 
You know, it's amazing to me how even after using Take Command for years (and 4NT, 4DOS, etc. long before that), I still keep finding out about entire sets of features I knew nothing about. So first, thanks for the overdue schooling. Second, I'm having a couple of problems with using regular expressions:
  1. When I use the command "FFIND /s ::.+-Help\.xml", I would expect it to find any files whose names end with "-Help.xml" but it finds nothing. Interestingly enough, I can use "FFIND /s ::-Help\.xml$" to find exactly the files I seek. I get why the latter works, but I don't understand why the former fails. Do you?
"::-Help\.xml$" is the correct syntax; I'm not enough of an RE expert to tell you what's happening with the other syntax. TCC uses the RE expression library from Ruby (Oniguruma), and thus far when there's been a disagreement between users and Oniguruma, Oniguruma has always been right. :)
I'm so used to using FFIND that it never occurred to me to use the "simple" DIR command to search for files (dumb, I know), but when I use the command "DIR /s ::-Help\.xml$" it lists a few files and then crashes Take Command completely.
It is impossible for a DIR command to crash Take Command. It could conceivably crash TCC, but that would leave Take Command unaffected. (Although if you only have one tab and have configured Take Command to exit when no tabs are active, a crash in the sole tab would close Take Command immediately.)

I can't reproduce the crash here. Are you using the 32-bit or 64-bit version of Take Command / TCC? Do you have a .GPF file with the stack info?
 
Sorry, I lost track of this thread. Where would I find a .GPF file? I'll be happy to provide any details I can, but a quick ffind of my entire drive reveals no *.GPF files. In response to your question, yes, if I enable the /B option with dir it still takes down the whole TakeCommand application.
 
Sorry, I lost track of this thread. Where would I find a .GPF file? I'll be happy to provide any details I can, but a quick ffind of my entire drive reveals no *.GPF files. In response to your question, yes, if I enable the /B option with dir it still takes down the whole TakeCommand application.

If TCC can crash Take Command, we can sue Intel and Microsoft for billions for promoting a gigantic hoax. (No such thing as separate sessions or memory protection!?)

Unfortunately, the more likely cause is you have a single tab window and have configured Take Command to close when there are no tabs open. So when TCC closes, Take Command closes as well.

A *.gpf file would normally be in the default TCMD.INI directory. It's location varies depending on the Windows version; if you haven't changed your TCMD.INI location you can see it on the OPTION dialog title bar. On Windows 7, it's typically at "\users\yourname\Appdata\local\jpsoft". (It won't show in a quick FFIND unless you told FFIND to search hidden directories.)

Still not able to reproduce your problem here.
 
That's weird, insofar I can reproduce it on every machine I try it on. For what it's worth, I'm attaching a GPF file produced on my main computer at home.
 

Attachments

I reproduce this bug, too. I navigate to c:\windows, and from there I run:
DIR /s "::-Help\.xml$"
After a few seconds the output starts streaming out on the screen, but after a few screens of output, the TCC prompt tab within TC crashes and disappears.
This happens with most regexes that I've tried from c:\windows. For instance, it happens with:
dir /s ::\.x
However, it doesn't seem to happen when I run it from other directories. Maybe it's bumping into a junction or symbolic link?
(Windows 7, x64, TCC build 46)
 
I can reproduce a TCC crash (by issuing DIR /s "::-Help\.xml$" from c:\windows), but it does not kill TCMD. I don't think that it is a link issue because I have an alias for DIR that always adds /nj to avoid problems with recursive links.

TCMD.GPF file:

TCC 12.11.76 x64
Module=C:\Program Files\JPSoft\TCMD12\onig.dll
Address=6B3E975C
Exception=C0000005
RX=6B405D50 RBX=00000000 RCX=00000048 RDX=00000048
RSI=00000002 RDI=00000048 RBP=016C5BD1 RSP=016C5B20
CS=00000033 DS=0000002B ES=0000002B SS=0000002B
Flags=00010202

Stack:
1 : onig.dll 000000006b3e975c
2 : onig.dll 000000006b3e9f4d
3 : onig.dll 000000006b3dcfa6
4 : onig.dll 000000006b3e0057
5 : onig.dll 000000006b3dffa2
6 : onig.dll 000000006b3e0639
7 : onig.dll 000000006b3e0920
8 : TakeCmd.dll 00000000100934de
 
OK, I tried a few more times. Right now, it is consistently crashing with just /s or with /s /nj, but consistently not crashing when adding /b (even without /nj).
This is odd, because, if I understand correctly, the regular is expression is only applied to the name, anyway, and not to the rest of the output line.
 
By the way, if I first redirect it to a file:
[c:\windows] dir /s > temp
And then run ffind:
ffind /e"Help\.xml" /v /8 temp
It works just fine.
(The dollar sign only works with ffind if I precede it with a \r, like this:
ffind /e"Help\.xml\r$" /v /8 temp
A little strange - the Regex libraries I'm used to don't insist on an explicit \r at the end of the line - but I guess that's how this library works.)
 
DIR /b /s /nj "::-Help\.xml$"

Does that crash?
As I said in my original message, I'm using /nj anyway (I have aliases for pretty much every command that supports that switch) but I get exactly the same crash using the command you gave (although I'm guessing that my onig.dll will be older than in the current release) to the extent that the TCMD.GPF is identical to the one I posted above.
 
Just my $0.02, but I don't think it's at all reasonable to expect users to know that a simple "DIR /s" is pointless and wrong, given that it has been the "canonical" command to find a file in a folder and all its subfolders.
 
Back
Top
[FOX] Ultimate Translator
Translate