#327 problem with strsub

[Ekkehart Schlicht]

The following code works fine:

string s  = "\\"
string r  = "/"
string TVCdir = strsub($dotdir, s, r) ~"/functions/TVC/examples/OkunGer.gdt"
open  @TVCdir
include TVC.gfn
set seed 10
series RND1=normal()
list L= intercept gGDP RND1
TVC(dU,L,"1,0,0",0)             # a function call that writes the file 
                                                                                            # $dotdir~"/functions/TVC/TVCbundle.xml"
s ="\\"
r = "\"
string TVCbundle = strsub($dotdir~"/functions/TVC/TVCbundle.xml", s, r)
bundle B=bread(TVCbundle)
printf "With seed 10 for RND1, R-squared is %g\n",B.R2

but if I delete the two lines after the function call to TVC() (which are identical to the first two lines of the code), I get an error. I did not expect that
.
Further,

string TVCdir = strsub($dotdir ~"/functions/TVC/examples/OkunGer.gdt", "\\", "/")
open  @TVCdir

gives the error unmatched '"'. I don't understand that either.

Cheers
Ekkehart.

[Sven Schreiber]

Here are some explanations and remarks:
1. You want to have a backslash character in s, but instead you get two, so the first invocation of strsub should actually have no effect. Quoting from the user guide: "Note that when you define a string variable using a string literal, only a single escape sequence is recognized: if a backslash is immediately followed by a double-quote character this is interpreted as an embedded quote. Otherwise all characters are treated literally. If you wish to use backslash-escapes to denote newlines, tabs and so on, use the sprintf function instead." (Just do a 'print s' after defining s to see what's in it.)
2. As a side effect, this shows that mixing forward and backward slashes actually seems to work OK.
3. Since the 'open' command (without the --preserve option) clears out all defined variables, it is logical that s and r are unknown if you do not re-define them. So that's expected. (BTW, the lines are not identical, since now r holds a backslash instead of a forward slash.)
4. The unmatched error is indeed a little puzzling and may be a bug. It looks as if the second string argument definition does not obey the rules that the user guide specifies for a string literal, as quoted above. We'll have to check that. As a workaround, you can pre-define s again as you did before, or you can use sprintf("\\") instead of just "\\".

Thanks, Sven

[Ekkehart Schlicht]

Thanks. I initially used "\" rather than "\\". The latter was suggested by CoPilot (ChatGPT) when I tried to get suggestions from there.
The --preserve option for the open command does the trick.
Thanks a lot!
Ekkehart

[Sven Schreiber]

Internally we discussed that indeed the escaping (or non-escaping) rules in literal strings need to be straightened out, but we are postponing this to after the next release.