in reply to Generating a grep command at run time

Thanks t,
but the above does not work.
grep -e '^04' is ok but grep -e '^(04|05)' does not work. (HP-UX 11)
Secondly wouldnt a grp pattern file be faster than reading the file line by line and pattern matching like this  $_ =~ /^(04|05). Thanks for your input again

Replies are listed 'Best First'.
Re: Re: Generating a grep command at run time
by Limbic~Region (Chancellor) on May 22, 2003 at 12:59 UTC
    chimni,
    HPUX does things a little differently when it comes to grep. You are going to want to change the grep to an egrep without the -e option and it should work fine. As an alternative, you could leave it as grep and change the -e to a -E option. See the local man page on grep to see why this works.

    Cheers - L~R

Re: Re: Generating a grep command at run time
by hardburn (Abbot) on May 22, 2003 at 13:54 UTC

    Secondly wouldnt a grp pattern file be faster than reading the file line by line and pattern matching like this $_ =~ /^(04|05).

    I doubt it. Grep has to read the entire file in, too, so you're not saving anything in disk access. There might be some speedup if grep on your system is implemented to read normally instead of line-by-line. Really, from a speed point of view, it will all come down to whichever program has a more optimized regex engine. In practice, the extra expense of just executing grep will probably make up for any lost speed.

    Further, I wouldn't worry about speed at all. The pure-Perl soultion will work just fine. Relying on external programs like this is generally a Bad Thing (tm). There are many problems with using external programs, not the least of which is potential security issues. It also tends to make less maintainable code.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

      hardburn,
      I have to completely disagree with you. The *nix utility grep is a compiled C program specifically designed for a single task. I worked very hard to modify tcgrep to be nearly as fast as the *nix grep. This only worked because of my very specific problem and still failed miserably in a general sense.

      I am not sure what you mean by read normally instead of line-by-line. As best as I can tell, both Perl and grep see the file as a data stream. They read data into a buffer, they then process that buffer "line-by-line" by terminating on the newline character. The speed difference would be if the default buffer size is different - i.e. actual less physical reads as they only go back out to disk when the buffer is empty.

      I agree that Perl offers all the functionality of the *nix grep and more, so resorting to using it for any reason other than raw speed seems like a bad idea. I would say that the reason not to use it isn't because of security or maintainability even though these are very valid points. To me, it is because of portability. This isn't even a matter of Win32 vs *nix portability - as can be seen in this thread.

      Cheers - L~R

        Hi limbic-region
        thanks for your assistance.I finaly got the job done

        I am not sure what you mean by read normally instead of line-by-line.

        I mean doing read(FH, $buf, $size); instead of my $buf = <FH>;. The plain read() call is faster than line-by-line reading, though generally harder to program around for many practical purposes. Most of the time, disk access will be a greater factor than the method of reading the file, so it's not something that I lose sleep over.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        Note: All code is untested, unless otherwise stated