On Wed, Feb 07, 2007 at 10:01:49AM +0100, Paolo wrote:
> Package: grep
> Version: 2.5.1.ds2-6
> Severity: wishlist
>
> hi,
>
> at first it lokked like a bug, but then after digging into the docs I'm
> rating it a wishlist item.
What docs changed your mind?
> Seems that grep fails on simple basic regex:
>
> % echo -e '\t0000\t:ris'|egrep '^\t0000'
It seems grep doesn't know \t, so it parses it as '\' followed by 't'.
sed.info has:
Note that the only C-like backslash sequences that you can portably assume
to be interpreted are `\n' and `\\'; in particular `\t' is not portable,
and matches a `t' under most implementations of `sed', rather than a tab
character.
And grep doesn't know \n.
> But even agrep seems broken here:
>
> % echo -e '\t0000\t:ris'|agrep '^[ \t]0000'
>
> fails. [ \t] would be [:blank:] and with that both *grep work.
No; grep.1 says:
Most metacharacters lose their special meaning inside lists. To
include a literal ] place it first in the list. Similarly, to include
a literal ^ place it anywhere but first. Finally, to include a literal
- place it last.
> Funny is, that sed (4.1.5) works:
>
> % echo -e '0000\t:ris'|sed 's/^0000[ \t]\(.*\)/\1/'
> :ris
sed.info:
(1) All the escapes introduced here are GNU extensions, with the
exception of `\n'. In basic regular expression mode, setting
`POSIXLY_CORRECT' disables them inside bracket expressions.
$ echo -e '0000\t:ris'|POSIXLY_CORRECT=t sed 's/^0000[ \t]\(.*\)/\1/'
0000 :ris
The pattern is not matched, since the 4th zero is followed by none of: "space,
slash, or t", but rather a tab. So no substitution is done.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
