|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |