>> Or rather, I'd rather write my own program than use grep for a *complex* 
>> search. (E.g., find anything that's a valid XML fragment.)
> 
>   Don't start making unfair comparisons. 'grep' (as well as other similar
> tools such as 'sed') is a line-based tool. It can match individual *lines*
> of the input. It cannot be used to perform operations which would require
> interpreting several lines (unless it has some non-standard extensions).
> 
>   Recognizing a valid XML fragment would require interpreting several lines
> of the input (if you want to be able to match all possible cases), and hence
> 'grep' cannot be used for that.

Right. And when I do text processing, this is the kind of task I usually 
want to do. Which is perhaps why grep doesn't sound especially useful to me.

Still, if your goal is just to find out if (or where) a file contains a 
particular word or code number, I agree that grep is probably the 
fastest way to find it.

>   'grep' is most useful for finding things you know are all in one line,
> and for filtering files with a known format (such as httpd logs).

I gather line-based file formats are quite common in Unix. (E.g., fstab 
is line-based, IIRC.) Such things are comparatively rare for Windows 
though. About the closest thing is CSV files. But - as I recently 
discovered - CSV isn't really line-based. (A single record can span 
multiple lines. At least, according to the RFC.)

>   If you need more complicated things like that, then often 'awk' or 'perl'
> can be used (still usually with shorter commands and faster than writing
> your own program would).

I would debate that, but let's not start another argument...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message