I am using Windows XP SP3. I have read a file into string for searching.
Here are the first few characters of that file printed on the screen with a string slice. String name is a.
"Rar! 26 07 00207144s 00 00r"
find seems to work ok, but using find-all works a little different.
(find-all " 26 07" a) will return a lot of hits for " 26 07" (as it should).
(find-all " 26 07 00207144" a) also returns a lot of hits for " 26 07".
It should be returning a lot of hits for the original search string:
" 26 07 00207144".
I am wondering if it is really finding that number of search strings or if the the 00 value in the string is messing up the the returned list.
I think you have to double quote the find string
(find-all "\000\000\003" data)
or use { 00 00 03}
(find "xxxxxx" data) works just fine without doubling up on the inverse slashes.
If I put double slashes in find-all, it returns an empty list. If I use left and right braces instead of the double quotation marks, it also returns an empty list. If I use braces and double inverse slashes, it returns an empty list.
The only way I can get it to return anything but the empty list is this:
(find-all "xxxxxx 00xxx" data)
Then it chops off the list elements beginnin with the null byte.
I am using version 10.0.2. I also tried using the UTF-8 version. Things got really nasty then. Thanks for you quick reply.
In PRCE (Perl Compatible Regular Expressions) a binary zero ends the search pattern. See http://www.newlisp.org/downloads/pcrepattern.html .
But you can have 0's in the searched string:
> (set 's " 01 02 02 00 01 02" )
" 01 02 02 00 01 02"
> (find-all " 01" s)
(" 01" " 01")
> (find-all " 02" s)
(" 02" " 02" " 02")
> (find-all " 02| 01" s)
(" 01" " 02" " 02" " 01" " 02")
> (find-all " 01 02" s)
(" 01 02" " 01 02")
>
ps: With 'find-all' all searches are regular expression searches. With 'find' the search is a plain search if no options number is given (see manual).
... and the plain search with 'find' may have binary zeros in the search pattern.
Thank you guys for your help.
I used the new function "search" that scans file content in an open file.
I believe it will do what I want it to do.
However, the manual states that after a search the file pointer is positioned
to the end of the search string by default. Incorrect. The file pointer is
positioned to the beginning of the search string.
I used a bool-flag of true in the third parameter to have it position the
file pointer to the end of the search string.