Running [Re: Thanks [Re: ragrep newbie question ?

[Stéphane Peters]

Hi Carter,

ragrep is running nicely with my current file of 70 patterns,
with the same output as before, ie without a filename,
and the/ "-i -v -f <file>"/ options.
I hope to feed it the large regexp file on monday.

I have tried the -e -i -v -f -H -L -l -q options, that work as expected;
there are still minor differences between the usage text and the behavior:
- the -b option dumps the filter code instead of printing the byte offset
- the -c option doesn't need <char> in its new behavior, count lines, 
     instead of the previous one, delimiter char.



Carter Bullard a écrit :
> Hey Stéphane,
> I just uploaded argus-clients-3.0.3.5.tar.gz to the developers web page.
>    http://qosient.com/argus/dev/argus-clients-3.0.3.5.tar.gz
>
> It has all the changes to ragrep() that you suggested in your email.
>
> Carter
>
>   
>> Carter Bullard a écrit :
>>     
>>> Hey Stéphane,
>>> I fixed the -v option and updated the usage().  Added the 'H' and 'h' options to
>>> control filename printing on output.  I'll upload a new clients tomorrow that should
>>> have all these fixes.
>>>
>>> If you run any ra* program without any data source specified in the .rarc or on the
>>> commandline, they will all block reading for input on stdin.  So that's the correct behavior.
>>>
>>> To deal with the collisions of options, I'd suggest that we pipe the output to ra().  While
>>> that may not be 100% of what you want, it is the easiest for getting similarity to grep()
>>> and its options,  and still providing all the ra() functions.
>>>
>>>    ragrep -r file -e 'whatever' -w - | ra -L 24
>>>
>>> The 'e' option was changed for all ra* programs in 3.0.x.  The encoding option is now done
>>> with a "-M encode" option.
>>>
>>> Hope all is most excellent,
>>>
>>> Carter
>>>  On Mar 24, 2010, at 11:31 AM, Stéphane Peters wrote:
>>>       
>>>> Hey Carter,
>>>>
>>>> sorry for having left you without any news for such a long time !
>>>> Thank you for your fast suggestion of ragrep with the -f option!
>>>> Just one thing,  the -v option shows an odd behavior, more on that later.
>>>>
>>>> As usual, argus was the tool of choice in this case:
>>>> it was able to show traces of infections,
>>>> both in real time and in past data several weeks (and even months) before,
>>>> thanks to the data reduction obtained by the flows records.
>>>>
>>>> I must say that I still haven't attained the first limit of about 200 patterns inline with the direct RE,
>>>> but I like your idea of a large buffer.
>>>>
>>>> With a space of 16K patterns, and the "-v" option, my work can be reversed :
>>>> I am building a white list of accepted/known good DNS names to narrow the search for virus evidences.
>>>> Let's see if it is manageable...
>>>>
>>>> Here are some suggestions about ragrep:
>>>> - the filename is appearing on stdout when reading a single file; how could it be controlled (hidden)?
>>>>   perhaps with the "-s +filename" option?
>>>> - the -L option seems conflicting with "-L0";  how could I show the titles ?
>>>>   perhaps could we choose +l / -l to control the printing of the filename ?
>>>> - the usage text doesn't talk about -f / -l / -L / -i options,
>>>>   and shows "Ratemplate Version 3.0.3.4"
>>>> - the -e option is conflicting between expression and encoding,
>>>>   I haven't used it before but, who knows ?
>>>> - the -v option seems inactive, here are some attempts,
>>>>   comparing ragrep(3.0.0.rc.70) with ragrep(3.0.3.4):
>>>>
>>>> the -v option is parsed in the new version
>>>>         
> [snip] ......
>
>   
>>>  
>>>       
>
>   
Regards,

-- 
Stephane.Peters at forem.be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100326/af321085/attachment.html>