NY wrote:


I wish I could find a decent Windows version of grep for pulling out all
the lines (maybe with line numbers) from multiple files. It's often
quicker to use grep to locate any emails that contain a certain phrase
than it is to use Windows Live Mail's Find facilities when you've got
many thousands of emails to search through. Unfortunately the version
I've got can't handle long file names so it tells me that the match is
in 2CD672AE~1.eml and I then have to do a dir /n /x to match that short
name to the long name so I know which file to open.


I use the packages from gnuwin32. For some of your Linux/Unix favorites,
you have to know which package they're in (i.e. FindUtils has a bunch).
And for some, you get an easy ride (package labeled "grep").

http://gnuwin32.sourceforge.net/packages.html

The programs consist of a binary and supporting DLLs.
The binary must be next to the DLLs, or the %path% variable
set up to make it all happen. In the case of the "file" command,
the one that identifies file type by content, the library
that program uses must be arranged at a specific relative location
with respect to the executable. (It's not good enough to put "magic"
file next to "file.exe".)

So setting those up is the fun part. They do provide complete
setup utilities, but after a while, I use the "soup recipe"
to "pour them in the bowl I want". In other words, you don't
need an installer, if you know what you're doing.

If I'm working on a project, I just copy the exe and dll files,
into the directory I'm working in. And run Command Prompt
from there.

The GNU utils aren't perfect. I think the grep one, likes to
store stuff in RAM. If you want to grep a file which is 10GB
in size on a machine with 2GB of RAM, the program will complain
it is "out of memory". This is a far from optimal design optimization,
where the software developer didn't use the "out of memory" error
to switch back to traditional "piped" operation.

These days, one of the biggest questions to ask (in a Windows environment),
is whether the thing you're searching for, is in 16 bit Unicode, or
regular 8 bit characters. And whether the tool you're using, knows
the difference, or searches for both. Just in case you're wondering
why the old methods that used to work for searching content,
no longer seem to work right. For one little project I was
working on, I actually had to write a one-page C program,
to do the search for me. And load it with variants on 8 and
16 bit versions of text. And that worked.

Paul