Feature request: grep hex strings with -e

[Carter Bullard]

Hey Marrku,
Remember, ragrep() is still a standalone program where many of the esoteric grep options and cases are or should be implemented.  The -e option is suppose to be a quick grep option for all clients.

I think providing compile time choices is the best.  I don't think that multiple options for multiple regex strategies makes it easier or less complicated, so I'm not thinking that is a great way to go.

Lets do the work to find and use PCRE if its there, and then try to figure out how to get people to do the right thing.

Carter


On Oct 16, 2012, at 9:58 AM, Markku Parviainen <maketsi at gmail.com> wrote:

> Looking at the regexp comparison page in wikipedia, PCRE library seems
> to be the most comprehensive for all purposes. A compile time option
> would be one option, but would require more maintenance. That lib
> could be the default too if the library existed in the system.
> However, it should be very clear to an end-user which library was
> selected, as multiple libraries will break the compatibility with
> external scripts. Therefore you need to evaluate if the current
> library is in anyway better than PCRE (for example), besides being on
> (most?) systems already.
> 
> A simple alternative (or addition) to this particular case is to
> provide binary string matching via new command line parameter (e.g. -E
> "41beef" -> searches for string "A\xbe\xef"). That's easy to implement
> as it's almost like a direct memcmp, without any regexp features. If
> that -e regexp was better, this probably wouldn't be needed at all
> though, except for convenience. Binary searches are basically used
> when searching for known malware handshake patters, or when looking up
> known image or compression formats in data flows. Encryptions and
> snaplen used restrict the more advanced usage.
> 
> Extending and fixing the restrictions of the current -e parameter is
> another thing completely, but might be desirable too on some cases.
> Dave had many good points there. Alternative to some of those new
> flags could be supporting the more typical regexp format of
> [!]/regexp/modifiers, which supports inline negation and
> case-insensitivity switches, along with other extended modifiers (such
> as single/multi-line matching, affecting to behaviour of dot, \n, ^
> and $).
> 
> One problem with current -e format is btw. that how do you search for
> string "s:data" in both source and destination buffers, as currently
> that would search for "data" in source buffer only? But I guess that's
> quite an edge case, which is easily avoided.
>