I typically find myself using the Window Search all the time. It does a great job of finding files and documents by name, filtering the criteria by date or size, and I like having results in the graphical file explorer where I can sort by several attributes. If it could find my keys at 5:30 in the morning it would be the primary function on my laptop.
My recent experience with Search has been less satisfactory. I recently inherited several thousands of lines of HTML, asp, VB 6 and JavaScript code in hundreds of files that makes up a major portion of my employers web site. At the same time our database admins rolled out a new version of one of our primary databases that serves as a back end for several desktop and web applications. Unfortunately the web site wasn't checked thoroughly for dependency on the old database, nor compatibility with the new one. (That should be a topic for a whole separate stream of posts.)
Needless to say, this week has been one composed of frantic scrambling trying to figure out what was up and what was broken, and why. In a little bit of serendipity, I found that most of the applications used one particular configuration file in which was stored the connection information tagged with a label like 'ORA_CONNECT' (Nice job, previous developers.) When an application needed to connect it would call to the root config file and get the connection information by passing the label. Pretty standard stuff.
So, my first thought was to use the Windows Search to see if I could find all files that contained the string "ORA_CONNECT". So navigated to the root directory, fired up search, entered the parameters and waited with eager expectation after clicking on search. A long list of files came up, but shockingly it did not include the three files I had looked at by hand to determine what connection was being used.
Puzzled, I set up a little test. I created a directory with two subdirectories. In the root I put a text doc, and in the subdirectories I placed an HTML, ASP and MS Word file. Each file included text that contained the string ORA_CONNECT.
I ran search on that directory, and it found everything EXCEPT the use in the ASP page. I even went back and made sure that the All Files and Include Subdirectories options were enabled. Clearly Search was not reliable.
What will I FIND
I IM'd a co-worker about what I was tying to do, and he sent me a string using the FIND command. Ah Ha! Good old find! I had forgotten that since the last time I spent hours writing MS-DOS 5 batch files years ago. Oh No! Bad FIND...
As you can see from the image, access was denied to the subdirectories. FIND does not recurse. I knew I could write a batch to recurse the directories, and save the output to a file, etc, etc; but who has that kind of time?
FINDSTR /i /s ss64.com *.*
It was then that I remembered reading somewhere that there was a 'find' in windows that supported regular expressions like grep. I quick check of my links turned up the excellent site ss64.com - a command line reference site for SQL Server and Oracle, which just happens to have an XP/NT section.
The page on the FINDSTR command had just exactly what I needed:
Check out the command reference on ss64.com for other options, like printing the line and line number that match, and outputting the results to a text file.
Friday, October 05, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment