On Wed, Feb 07, 2007 at 10:09:12AM -0500, Justin Pryzby wrote: > > 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?
man/info for regex,sed,*grep; POSIX 1003.2 > 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 yep, that's one of the points. > And grep doesn't know \n. and not 8bit clean - but that's GNU's regex (too) ... > > % 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 yep, that's another of the points. I meant above line is commonly used in code in place of [:blank:]. Sed scripts are just one case. > `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. yes, that's the point of consistency: I'd expect same behaviour from such GNU tools, ie need to set POSIXLY_CORRECT to 'break' [ \t] for grep as well. Somehow, it sounds like an (albeit documented) bug that in a script '^[ \t]0000' would work in sed(1) but not in grep(1). thanks -- paolo GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4 "Indeed, it does come with warranty: it *will* fail." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
