regsub (and regular expressions in general) trouble.
in [TCL]
|
From: Jonathan Bromley on 24 Dec 2009 16:31 On Thu, 24 Dec 2009 01:29:56 -0800 (PST), Mark Morgan <admin.shortstacs(a)gmail.com> wrote: >Thank you very much! > >I hate to bother you, but I'm having a little bit of trouble with it >with the new changes. > >The line in my code is: > > regsub -all {\s*?\@INPUTFILE\s*?(\S.*?)\s*?} $s {[readFromFile >\1]} s > >I think the expression seems to be returning only the first letter of >the the filename, though. Sheesh, I just *knew* that would happen..... When I described the regular expression (RE), I hope the description made it clear that its opening and closing braces should match those same characters in the source text. In other words, they really form a part of the RE you want to process. However, that immediately caused an ambiguity that I didn't forestall. When you put a RE into a typical Tcl command, it's common to enclose the entire RE in braces because RE syntax contains a lot of characters that would normally have special meaning to Tcl - for example, square brackets - and it's usually wise to prevent the Tcl parser from manipulating them. (Another, possibly neater, method is carefully to put the required RE into a Tcl variable, and use that as the argument in preference to using a literal regular expression.) In our case, an additional pair of braces around the whole thing would have done the job: regsub -all {{\s*?\@INPUTFILE\s*?(\S.*?)\s*?}} $s ... Donal showed you exactly that, but also with backslashes in front of the braces that actually form part of the RE. This is sensible but not strictly necessary. Braces have a special meaning in REs, but when they appear in isolation (as in our RE) they don't have this special meaning and don't really need backslashes. There's a slightly embarrassing back-story to this: the RE visualiser that I wrote a while back [*] doesn't correctly deal with that situation, and gets a little confused if you include isolated backslashes in a sample RE. Blush. [*] http://www.doulos.com/knowhow/tcltk/examples/trev/ Since I no longer work for that organisation, I'm not easily able to fix the oversight..... oops. >There was a discrepancy between the stepwise description and the first >version (just a plus sign yeah, \s+ vs. \s* I don't think it would make much difference in practice. ), but that really had the same effect (just >finding the first letter of the filename) > >So if I've got "{@INPUTFILE staffpnp.txt}" it would just look for "s" Far worse than that; in the form you used, it was looking only for "@INPUTFILE...." and was taking no notice of the opening brace. Happy matching in 2010, -- Jonathan Bromley
From: Mark Morgan on 25 Dec 2009 22:57
Thank you very much! Happy Holidays, Mark |