Possible bug in regexp

[Jeffrey Hobbs]

In article <RGMANI.96...@dlsun280.us.oracle.com>,
Raghu Mani <rgm...@dlsun280.us.oracle.com> wrote:
>Tried doing some regular expression matching using the regexp command
...
>% regexp {^[ \t]*load[ \t]+file[ \t]+[^ \t\n]+[ \t]*$} "load file /private/rgmani/personal/interpreter/inputs/abp.EA" mmatch

When I first encountered this problem it annoyed me, but it's not a bug.
The problem is that 'regexp' will not interpret the \t and \n as <tab> and
<newline>, you have to get the tcl interpreter to do it for you. Dr. O has
considered updating the regexp, but it's not high on the ToDo list. Convert
the above to the following:

regexp "^\[ \t\]*load\[ \t\]+file\[ \t\]+\[^ \t\n\]+\[ \t\]*$" \
"load file /private/rgmani/personal/interpreter/inputs/abp.EA" mmatch

That should give you what you wanted. Remember to use ()s to get just the
filename. Of course, you could always use [lindex $str 2] to get the same
result.

--
Jeffrey Hobbs office: 541.683.7891
Nomad of the 'Net email: jho...@cs.uoregon.edu
URL: http://www.cs.uoregon.edu/~jhobbs/

[Bryan Oakley]

Raghu Mani wrote:
>
> Tried doing some regular expression matching using the regexp command

> and found that it wasn't working as it should. I have given an example
> below. The difference in the two cases is that in one the regular
> expression has a '$' at the end and the other does not. Is this a bug
> or am I doing something wrong?
>
> Raghu
>
> PS - I saw this problem with both tcl 7.4 as well as 7.5 on Solaris 2.4.
>
> rgmani(153): tclsh

> % regexp {^[ \t]*load[ \t]+file[ \t]+[^ \t\n]+[ \t]*$} "load file /private/rgmani/personal/interpreter/inputs/abp.EA" mmatch

> 0
> % regexp {^[ \t]*load[ \t]+file[ \t]+[^ \t\n]+[ \t]*} "load file /private/rgmani/personal/interpreter/inputs/abp.EA" mmatch
> 1
> % echo $mmatch
> load file /privat
> % exit

I believe the problem is that "\t" doesn't mean <tab> and "\n" doesn't
mean <newline>, like you think it does. From the regexp man page:

"An atom is ... a ``\'' followed by a single character (matching that
character)..."

So, \t means "t", not <tab>. However, \t is a tab when used in a quote
delimted string, but that means you have to escape the ['s and $. No, we
don't live in a perfect world, and tcl regular expressions certainly
don't have the power of Perl regular expressions.

Nevertheless, this will give you what you expect:

regexp "^\[ \t\]*load\[ \t\]+file\[ \t\]+\[^ \t\n\]+\[ \t\]*" "load file
/private/rgmani/personal/interpreter/inputs/abp.EA" mmatch

--
Bryan Oakley, Software Engineer
Healthcare Communications, Inc.
oak...@healthcare.com

[Raghu Mani]

[Larry W. Virden]

It sure would be nice if someone took the latest Henry Spencer regular
expressions and built a Tcl extension with them.
--
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.

[William Donovan]

I was unaware that these have been updated since 1986. Until recently
there has been very little added to the pot for REs. I have found a
few incomplete c versions, the GNU versions and about three new Java
class libraries. Just today, I located what I think we are looking
for at
http://vlsi19.gsfc.nasa.gov:8224/software/software.html#libgpl

This c library software by Alex Measday is by far the most complete
and professionally done that I have found yet. I have not used it yet
so a lot of testing wouldn't hurt.

I am not a SWIG expert but I bet someone who is could wrap this lib
and test it in an hour. That would provide an alternative to the
builtin.

[Eric Vought]

> This c library software by Alex Measday is by far the most complete
> and professionally done that I have found yet. I have not used it yet
> so a lot of testing wouldn't hurt.
>
> I am not a SWIG expert but I bet someone who is could wrap this lib
> and test it in an hour. That would provide an alternative to the
> builtin.

With a quick look, you're probably right, it wouldn't take long to wrap-
probably more than an hour, but certainly not that long. Such an
extension would replace a *lot* of the builtin Tcl functionality,
however. It would, in effect, become another language with a Tcl syntax.
We could wrap just RE's, but we'd have to extract the code- no sense
carrying around a library of that complexity for just a handful fo
func ions. This might make the task more complex, *if* the the RE
functions are dependent on many other functions in the library.