scott <sco### [at] scottcom> wrote:
> >> Or, in Windows, you can just type the string into the top right of any
> >> explorer view, in the box that says "Search".
> >
> >  I wish it worked. It doesn't.

> Works fine here - I just tested it by typing in "Vector3" (used in XNA game 
> studio to represent a 3D vector) and within about 1 second the explorer 
> window had filled up with lots of C# source code files, plus lots of POV 
> source files (I guess it uses Vector3 too).

  Lucky you.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Heh. I didn't know the shell could do that either. (Although you didn't 
> specify *which* shell - Unix has several...)

  I don't think there's a unix shell in existence that doesn't do file name
pattern expansion. It would be a rather useless shell if it didn't.

  The shell doing the expansion rather than the program is a rather clever
idea. In DOS it was always the program which did the expansion, which meant
that many programs didn't support expansion patterns because the programmers
were lazy. It's also handy because a more advanced shell can support more
complex expansion patterns without the need for the programs to support them.

  The program just ends up seeing a bunch of file names in the command line
(because the shell expands them before even launching the program).

> I'm still not seeing what's so useful about being able to search a file 
> for something.

  Suppose that you have a httpd log file and you want to list all entries
within a specific day. Or the number of requests for a specific file (or
a group of files). Suppose you want to list all entries *except* those
which match a certain pattern (eg. they have a referrer which indicates
that the request was made by a search engine). 'grep' is your tool for that.

> Now, I suppose if you were trying to script something, being able to 
> pipe output from another command into grep so that it can grab a 
> particular substring that you can then pipe to something else might be 
> useful. But then, if *I* wanted to do something like that, I wouldn't 
> script it. I'd write a real program, not a script.

  Filtering some files through a chain of programs (such as grep and sed)
takes just a few seconds of writing a few commands on the command line.
Writing a program to do that would probably take a hundred times longer.

> I never have 50 small files.

  Haha. You are quite humorous sometimes.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I still don't get why you'd need to do complex searching. And if for 
> some strange reason you do need to, why use an obfuscated text string 
> with limited processing capabilities when you can use a real programming 
> language?

  Because you can write a simple search pattern in a matter of seconds,
while writing the equivalent program would take you minutes at least.

-- 
                                                          - Warp

Post a reply to this message

>  Lucky you.

Computers don't work on luck :-)

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I still don't get why you'd need to do complex searching. And if for 
>> some strange reason you do need to, why use an obfuscated text string 
>> with limited processing capabilities when you can use a real programming 
>> language?
> 
>   Because you can write a simple search pattern in a matter of seconds,
> while writing the equivalent program would take you minutes at least.

Um... why? Three lines of text doesn't take "minutes" to write. And 
that's about all it takes to search a folder for a file matching a 
condition. (Obviously, it depends on how complicated the condition is...)

Post a reply to this message

scott wrote:

> Computers don't work on luck :-)

Some days I start to wonder... :-S

Post a reply to this message

Warp wrote:

>   The shell doing the expansion rather than the program is a rather clever
> idea.

Yeah. But then, it's part of the general Unix philosophy of "make each 
tool do one job, and one job well".

With MS-DOS/Windows, the shell's job is basically to launch the 
interactive programs that do all the *real* work. The shell itself is 
pretty poor. (Although not quite as poor as it seems at first...)

>> I'm still not seeing what's so useful about being able to search a file 
>> for something.
> 
>   Suppose that you have a httpd log file and you want to list all entries
> within a specific day. Or the number of requests for a specific file (or
> a group of files). Suppose you want to list all entries *except* those
> which match a certain pattern (eg. they have a referrer which indicates
> that the request was made by a search engine). 'grep' is your tool for that.

Ah, right. I see.

Personally, I'd import the whole log into a relational database, and 
process it that way. (Or maybe even use a webserver that keeps its logs 
in a database in the first place, rather than a huge flat file.) But 
apparently that's just me...

>> Now, I suppose if you were trying to script something, being able to 
>> pipe output from another command into grep so that it can grab a 
>> particular substring that you can then pipe to something else might be 
>> useful. But then, if *I* wanted to do something like that, I wouldn't 
>> script it. I'd write a real program, not a script.
> 
>   Filtering some files through a chain of programs (such as grep and sed)
> takes just a few seconds of writing a few commands on the command line.
> Writing a program to do that would probably take a hundred times longer.

On the contrary, figuring out how to work grep vs writing a program in a 
language I already know well is likely to take *slightly* more than 
merely a hundred times longer. (Although you could argue that's a 
one-time cost.)

Personally I just dislike scripting languages. I'd rather use a real 
language with propper error checking and so on and so forth. But I guess 
that's just me.

>> I never have 50 small files.
> 
>   Haha. You are quite humorous sometimes.

Maybe I just don't try to do the same kinds of tasks as you?

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Personally, I'd import the whole log into a relational database, and 
> process it that way. (Or maybe even use a webserver that keeps its logs 
> in a database in the first place, rather than a huge flat file.) But 
> apparently that's just me...

  Talk about an overly complicated solution for a simple problem.

> On the contrary, figuring out how to work grep vs writing a program in a 
> language I already know well is likely to take *slightly* more than 
> merely a hundred times longer. (Although you could argue that's a 
> one-time cost.)

  Writing something like "grep 'hello.*there' file.txt" doesn't require a
lot of time or thinking.

> Personally I just dislike scripting languages. I'd rather use a real 
> language with propper error checking and so on and so forth. But I guess 
> that's just me.

  What's the difference between "a scripting language" and "a real language"?

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Um... why? Three lines of text doesn't take "minutes" to write. And 
> that's about all it takes to search a folder for a file matching a 
> condition. (Obviously, it depends on how complicated the condition is...)

  How long does it take you to write a program which does the same thing
as this:

    fgrep '#include "header.hh"' *.cc

  How long does it take to write the program *and* compile it *and* run it?
Why would you do that when you *already* have a program which does that
(namely 'grep')?

  And I didn't even use any wildcards there.

-- 
                                                          - Warp

Post a reply to this message

>> Personally, I'd import the whole log into a relational database, and 
>> process it that way. (Or maybe even use a webserver that keeps its logs 
>> in a database in the first place, rather than a huge flat file.) But 
>> apparently that's just me...
> 
>   Talk about an overly complicated solution for a simple problem.

Once the data is in a real database, you can sort it and search it and 
compute stats on it and basically do whatever you want with it, 
effortlessly and easily. But sure, if you *only* wanted to quickly see 
if a particular IP address appears or something, you could use a text 
search. But if I was hunting through web logs, I'd probably want to 
build all sorts of statistics or do multi-way searches - the exact task 
that databases are especially designed to perform. Why not use the right 
tool?

>> On the contrary, figuring out how to work grep vs writing a program in a 
>> language I already know well is likely to take *slightly* more than 
>> merely a hundred times longer. (Although you could argue that's a 
>> one-time cost.)
> 
>   Writing something like "grep 'hello.*there' file.txt" doesn't require a
> lot of time or thinking.

Nor does opening file.txt in a text editor and running a quick search. 
(Not that I can think of a reason to want to do this in the first place...)

>> Personally I just dislike scripting languages.
> 
>   What's the difference between "a scripting language" and "a real language"?

Now that is surprisingly hard to pin down. ;-)

Post a reply to this message