>> 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

Orchid XP v8 <voi### [at] devnull> wrote:
> >   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...

  Are you saying that you don't think one could write a significantly
shorter command using perl than with your favorite language? Maybe you
just don't know that perl can be used directly from the command line,
giving the "program" as an argument, and hence it can be used very much
like grep or sed. For example:

    perl -pe 's|\d+|$&+1|ge' file.txt

  This searches for any consecutive digits in 'file.txt', interprets them
as numbers and outputs the contents of the file but with each of these
numbers incremented by 1. (Thus if the file had a something like
"value = 123;" somewhere, the result would have "value = 124;" instead.)

  I don't know Haskell too well, but I'm pretty certain it takes a bit
more code to do that (and additionally you probably can't just write the
code on the command line).

  (And yes, I know that the string given to perl looks gibberish to you.
It's not gibberish when you understand what it means.)

  Of course this is just a simple example. Perl can be used to make
significantly more complex substitutions (and other things) in a similar
way.

-- 
                                                          - Warp

Post a reply to this message

>> I would debate that, but let's not start another argument...
> 
>   Are you saying that you don't think one could write a significantly
> shorter command using perl than with your favorite language?

...alternatively, let's start another argument... *sigh*

> 
>     perl -pe 's|\d+|$&+1|ge' file.txt
> 
>   This searches for any consecutive digits in 'file.txt', interprets them
> as numbers and outputs the contents of the file but with each of these
> numbers incremented by 1. (Thus if the file had a something like
> "value = 123;" somewhere, the result would have "value = 124;" instead.)
> 
>   I don't know Haskell too well, but I'm pretty certain it takes a bit
> more code to do that

It does. (If only because of the difficulty of number parsing.) But a 
more relevant question would be... why would you want to do this? Is 
Haskell (or anything else) easier or harder for textual manipulations 
that actually do something useful?

> (and additionally you probably can't just write the
> code on the command line).

Actually you can. (But obviously you *only* want to do this if the code 
is short...)

>   Of course this is just a simple example. Perl can be used to make
> significantly more complex substitutions (and other things) in a similar
> way.

Again, I guess it depends on what you want to do. For example, some guy 
invented "markdown", and wrote a Perl script to turn it into HTML or 
whatever. And then a bunch of Haskell guys wrote their own 
implementation, which was faster, had fewer bugs (i.e., it matched the 
documentation more closely), and had more features.

Then again, not every task is as complicated as markup conversion...

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> why would you want to do this?

  Why would one want to do pattern substitution?

  Obviously nobody wants to do that, which is why there are no tools to do
that from, like, forever, like eg. 'sed' or 'perl'.

  I'm sure even you have used search&replace. This is the same, except that
it's significantly more expressive and can be automated.

-- 
                                                          - Warp

Post a reply to this message

On Sat, 24 Apr 2010 09:04:40 +0100, Orchid XP v8 wrote:

> Nicolas Alvarez wrote:
> 
>> Yesterday, the 'parted' tool was giving me a totally cryptic error
>> message.
>> 
>> $ apt-get source parted
>> $ cd parted-2.2
>> $ grep -rn "error message here" .
>> 
>> -r makes search recursive, -n makes grep output line numbers next to
>> the filenames. Then I opened a text editor on the file and line number
>> that grep mentioned, and tried to figure out the code :)
> 
> Isn't trying to figure out why an arbitrary piece of code doesn't work
> formally equivilent to the Halting Problem? (With non-termination simply
> being the most basic kind of program bug...)

You're not asking grep to tell you why it failed, just to tell you where 
in the code the error is so one can manually inspect the file and see if 
one can determine why the failure occurred.

Done that many times myself.

Jim

Post a reply to this message

Orchid XP v8 wrote:
> Isn't trying to figure out why an arbitrary piece of code doesn't work 
> formally equivilent to the Halting Problem? 

No.

The code works, in the formal sense. It just doesn't do what you want it to do.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

Orchid XP v8 wrote:
> Such things are comparatively rare for Windows though. 

INI files is about it. Anything more complicated either goes in the registry 
or into an XML file, if it's configuration. Some log files actually go into 
text files, but that's mostly things like httpd logs there, too.

>> 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...

Using Perl *is* writing your own program. And I expect the parser generator 
in Haskell isn't a whole lot harder than an equivalet program in Perl.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

Warp wrote:
>   Why would one want to do pattern substitution?

Personally, I usually wind up wanting to do complex pattern manipulation on 
file names, rather than file contents.

Stuff like "go through these directories full of image files, figure out 
whether it's months, days, or hours that's changing, rename all the files to 
match the time they were taking excluding the parts of the date that's the 
same for all the files, tack on a letter saying which camera took the 
picture, then another letter to disambiguate multiple photos taken within 
the same minute.   Also, copy any sequence of three or more photos taken 
within 5 seconds of each other with a one-minute gap on either side to a 
separate directory to be stitched together as a panorama."

That's gonna be rough to do with command-line tools too. Not impossible, but 
certainly something easier in an actual scripting language better than Bash.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> Isn't trying to figure out why an arbitrary piece of code doesn't work 
>> formally equivilent to the Halting Problem? 
> 
> No.
> 
> The code works, in the formal sense. It just doesn't do what you want it 
> to do.

Or, to clarify...

If by "works" you mean "obeys the formal specification", then yes, you can 
prove it.  Write a formal spec for what sequence a Haskell program can 
output, such as a BNF grammar. Now analyze your Haskell program to see if 
the parser you wrote follows the BNF.

Computers do this all the time. There's an input language the compiler 
accepts. It can tell whether the input matches the language spec, and if so, 
the program "works", in some sense.

And indeed, this is called the field of "program verification", pioneered by 
those who invented structured programming and such.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

Orchid XP v8 wrote:
> Nicolas Alvarez wrote:
>> Invisible wrote:
>>> 3. It really takes that much code just to do the same task as DIR /B C:\
>>>  C:\FileList.txt?
>> 
>> Says the guy who would rather write his own program to do specific
>> searches than figure out grep :)
> 
> 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.)
> 

Well, sure. Regular expressions are almost always the wrong tool for XML.

Post a reply to this message