vValue = @XLU(@FN,mulit-value key, LE1 + "-" + LE7 + "-" + @Right(LE4,3) )

There are times, while using x-family commands and functions, there is no unique external key in a database with the use of one element but if one can combine two elements that would give Unique...

It would be nice if we do not have to go through loops and arrarys.

      The fundamental building blocks are the regular expressions that match a single character.  Most characters, including all letters and digits, are regular expressions that match themselves.  Any metacharacter  with  special  meaning may be quoted by preceding it with a backslash.

      A bracket expression is a list of characters enclosed by [ and ].  It matches any single character in that list; if the first character of the list is the caret ^ then it matches any character not in the list.  For example, the regular expression [0123456789] matches any single digit.

      Within a bracket expression, a range expression consists of two characters separated by a hyphen.  It matches any single character that sorts between the two characters, inclusive, using the locale's collating sequence and character set.  For example, in the default C locale, [a-d] is equivalent to [abcd].  Many locales sort characters in dictionary order, and in these locales [a-d] is typically not equivalent to [abcd]; it might be equivalent to [aBbCcDd], for example.  To obtain the traditional interpretation of bracket expressions, you can use the C locale by setting the LC_ALL environment variable to the value C.

      Finally, certain named classes of characters are predefined within bracket expressions, as follows.  Their names are self explanatory, and they  are  [:alnum:],  [:alpha:],  [:cntrl:],  [:digit:],  [:graph:],  [:lower:],  [:print:], [:punct:], [:space:], [:upper:], and [:xdigit:].  For example, [[:alnum:]] means [0-9A-Za-z], except the latter form depends upon the C locale and the ASCII character encoding, whereas the former is independent of locale and character set.  (Note that the brackets in these class names are part of the symbolic names, and must be included in addition to the brackets delimiting the bracket list.)  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.

      The period .  matches any single character.  The symbol \w is a synonym for [[:alnum:]] and \W is a synonym for [^[:alnum]].

      The  caret  ^  and the dollar sign $ are metacharacters that respectively match the empty string at the beginning and end of a line.  The symbols \< and \> respectively match the empty string at the beginning and end of a word.  The symbol \b matches the empty string at the edge of a word, and \B matches the empty string provided it's not at the edge of a word.

      A regular expression may be followed by one of several repetition operators:
      ?      The preceding item is optional and matched at most once.
      *      The preceding item will be matched zero or more times.
      +      The preceding item will be matched one or more times.
      {n}    The preceding item is matched exactly n times.
      {n,}   The preceding item is matched n or more times.
      {n,m}  The preceding item is matched at least n times, but not more than m times.

      Two regular expressions may be concatenated; the resulting regular expression matches any string formed by concatenating two substrings that respectively match the concatenated subexpressions.

      Two regular expressions may be joined by the infix operator |; the resulting regular expression matches any string matching either subexpression.

      Repetition takes precedence over concatenation, which in turn takes precedence over alternation.  A whole subexpression may be enclosed in parentheses to override these precedence rules.

      The backreference \n, where n is a single digit, matches the substring previously matched by the nth parenthesized subexpression of the regular expression.

      In basic regular expressions the metacharacters ?, +, {, |, (, and ) lose their special meaning; instead use the backslashed versions \?, \+, \{, \|, \(, and \).

      Traditional egrep did not support the { metacharacter, and some egrep implementations support \{ instead, so portable scripts should avoid { in egrep patterns and should use [{] to match a literal {.

      GNU egrep attempts to support traditional usage by assuming that { is not special if it would be the start of an invalid interval specification.  For example, the shell command egrep '{1' searches for  the  two-character  string  {1 instead of reporting a syntax error in the regular expression.  POSIX.2 allows this behavior as an extension, but portable scripts should avoid it.

Thanks Mark.

You have provided some guidelines, but I was wondering about more specifics re Sesame's usage.  For example you provide
Will Sesame use [a-d] or require [AaBbCcDd]?

(Hmm, just noticed the typo in the section from the manual).    Any phrases like [:digit:] to represent [0123456789] or [0-9] , or [:space:] to represent blank spaces?

I guess I am asking to see an advance of the Sesame manual's section on help for RegEx syntax. 

Since you have noted that this will be egrep compatible, then I will use that as a reference.  This could also mean that I can probably use most of any RegEx libraries that I have accumulated.

In addition to using RegEx in XL statements, will there be a RegEx based Search/Replace function for strings?  Or will the existing @Replace just be enhanced to use RegEx?

but the performance hit is substantial and there is no trivial way to make them optional.

It appears that while Posix.2 compliant and Sys V 8 compliant, the implementation is not a full implemenation of egrep's set, and does not support the extended classes (i.e. [:blank:], [:alpha:], etc...)

More importantly, I was hoping for search/replace to be used as string manipulation tools vs. just searching. Maybe with options to be turn Case Sensitive On/Off.  Would be good to be able to extract strings that meet RegEx Search specs.

Maybe two functions with optional file lines, that could allow executing against a variable or against a complete file, like

@RegexSearch(source, "RegEx Search Spec",[line]) returns the match as a string or "not found" and
@RegExReplace(source, "RegEx Search Spec", "RegEx Replace Spec",[line]) returns success/fail