| Andre Beck 2005-06-17, 7:45 am |
| Re,
when trying to optimize my voice translation rules used in translation
profiles, I've found out the hard way that something like
rule 1 /^\(8\(22\|23\|33\|[1-3]6\|[12]7\|[13]8\|3[159]\|[23][04]\)\)/ /\1/
^
% Invalid input detected at '^' marker.
will happen simply due to the fact that | is not implemented. This is
hard enough as it somewhere read that these are sed(1) style regexps and
I would expect them to support this syntax then, but it is probably correct
as sed(1) just specifies compatibility to POSIX 1003.2 BREs and they don't
have the | grouping. I was obviously fooled by GNU sed which does more
than the standard requires (as often with GNU tools, leading to all sorts
of hardly portable scripts).
When reading further about it, though, I found the page
http://www.cisco.com/en/US/tech/tk6...080325e8e.shtml
which gave me the creeps. Is the section about "number slicing", regarding
the workings of the backslash, really meant seriously? Or did someone who
never read anything about POSIX 1003.2 BREs just make something up that
made sense to him? Almost all examples use the backslash to escape the
parentheses as it is required in BREs but that section invents something
that makes no sense at all in either syntax or semantics IMHO.
So is this part of the doc just rubbish or do I have to drop all my
knowledge of BREs and restart with some arbitrary new concept of what
the backslash means here? And if so, what would that really be?
TIA,
Andre.
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"
-> Andre Beck +++ ABP-RIPE +++ IBH Prof. Dr. Horn GmbH, Dresden <-
|