Paul Eggert wrote:
In this particular case I'm afraid your memory has played tricks on you
---
You may be right ..;-(
I found these:
http://unix.stackexchange.com/questions/19491/how-to-specify-characters-using-hexadecimal-codes-in-grep
http://stackoverflow.com/questions/6319878/using-grep
Paul Eggert wrote:
Linda Walsh wrote:
Perhaps you want to tell me where the documentation on the
standard and/or extended RE's is that you use?
Here is another:
*POSIX Extended Regular Expression Syntax:
(http://www.boost.org/doc/libs/1_43_0/libs/regex/doc/html/boost_regex/syntax/basic
From the coreutils-5.97 info page:
Like I said, we're talking about grep, so you need to look at the grep manual.
grep is not part of coreutils, so you're barking up the wrong tree again.
It *used* to be compatible with 'awk's regex
No, that's never been true. It wasn't true even back in
Paul Eggert wrote:
Linda Walsh wrote:
Perhaps you want to tell me where the documentation on the
standard and/or extended RE's is that you use?
We're talking about grep, so the relevant documentation is the grep
manual, not the awk manual or other random stuff you might find on the
Intern
Linda Walsh wrote:
Perhaps you want to tell me where the documentation on the
standard and/or extended RE's is that you use?
We're talking about grep, so the relevant documentation is the grep manual, not
the awk manual or other random stuff you might find on the Internet. Type 'info
grep'.
Paul Eggert wrote:
Linda Walsh wrote:
it is documented, that '\ddd' or '\xHH' can be used
to match a single character of the value specified.
I don't see where it's documented to behave that way. Perhaps you're
looking at the wrong documentation?
Perhaps you want to tell me where the docu
Linda Walsh wrote:
it is documented, that '\ddd' or '\xHH' can be used
to match a single character of the value specified.
I don't see where it's documented to behave that way. Perhaps you're looking at
the wrong documentation?
The argument was that
a NUL in a file made it non-text -- the
Paul Eggert wrote:
Linda Walsh wrote:
I had one file that it bailed on
saying it has an invalid UTF-8 encoding -- but the line was
recursive starting from '.' -- and it didn't name the file
I didn't report that as 'a bug', because when I went back to reproduce
it -- low level physics t
Linda Walsh wrote:
I had one file that it bailed on
saying it has an invalid UTF-8 encoding -- but the line was
recursive starting from '.' -- and it didn't name the file
That's pretty vague. Can you reproduce that problem? I don't observe it:
$ mkdir d
$ printf 'a\200\n' >d/f
$ printf 'b\2
Eric Blake wrote:
On 05/23/2015 06:04 PM, L. A. Walsh wrote:
the standard & extended RE's don't find find NUL's:
Because NULs imply binary data,
I can think of multiple cases were at least 1 'nul'
would be found in text data -- the most prime example
being that it is a Microsoft Tex
On 05/23/2015 06:04 PM, L. A. Walsh wrote:
> the standard & extended RE's don't find find NUL's:
Because NULs imply binary data, and grepping binary data has unspecified
results per POSIX. What's more, the NEWS for 2.21 documents that grep
is now taking the liberty of treating NUL as a line termi
the standard & extended RE's don't find find NUL's:
dd if=/dev/zero of=zeros bs=4k count=1
command grep -Pq '\000\000' zeros && echo "badness"
badness
command grep -Eq '\000\000' zeros && echo "badness"
command grep -Gq '\000\000' zeros && echo "badness"
command grep -q '\000\000' zeros &
12 matches
Mail list logo
