At 11:59 AM +0900 9/8/11, Philip Spaelti wrote: >On 9. Aug 2011, at 11:01 , Robert B. Waltz wrote: > >> I'll tell you why it's a mess: ANY character preceded by \ should >>be treated as a literal, simply for consistency. I'm pretty sure >>this does not work, because of the odd results I've been getting. >>Unfortunately, I haven't yet identified the exact command causing >>my problems, but it appears that, somehow, a \t is being treated as >>a literal t! > >With all due respect what you are saying here is inconsistent. You >want \[char] to be treated as a literal and then you complain when >"\t" is treated as a literal "t" ;-) > >Of course "\" is the escape character which means that characters >following it are usually treated in a non-literal way. Only special >characters should (must) be treated literally after a backslash. NWP >does indeed do this correctly, to my knowledge. And "\t" should of >course be a tab, which it is. (And enclosing it in double quotes, >should just cause interpolation, i.e., turn it into an actual tab, >so this shouldn't cause a problem.) Beg to differ: Nearly all regex engines use a plain dot to mean 'any char except line break', and slash-dot to mean a literal full stop (or if you like, period). If Nisus have done this deliberately (which I doubt), they are seriously out of step with convention. See here: http://www.regular-expressions.info/refflavors.html The idea of an escape sequence is implementation-specific. The idea is to escape the usual meaning of a char _within_your_program_environment_. That can mean a usually literal char (such as t, b, n, r, s, ...) acquires a special meaning when escaped. And if your program usually applies a special meaning to a char (such as, maybe, <return>, '[', '\', '?' and '.' ) escaping it will return the literal meaning. Consistent this has never been (nor could it be). ..AD