(KiX Supporter)

2003-01-14 06:47 AM

4.20 RC1 - Problem with @CRLF & Strings & Execute ?

Ruud,

Not really too sure what to make of this but having some trouble interpreting @CRLF macros within the EXECUTE function "environment". Heres a snippet of code and all I really know at this point is that it "behaves" differently under 4.12 and 4.20:

code:

break on 
 
$= execute("$$var = '@CRLF'")
 
?"len=" len($var)
 
?
?"asc=" asc(substr($var,1,1))
?"asc=" asc(substr($var,2,1))
  
exit 1

Under 4.12 the output is:

code:

len=2
asc=13
asc=10

which makes sense - @CRLF is 2 bytes long made up of asc(13) and asc(10) - but the same code under 4.20 the output is:

code:

len=1
asc=10
asc=0

only one byte - an asc(10). So at the very least its some sort of backward compatibilty issue here. However this code does work under both versions - using double @@'s :

code:

$= execute("$$var = '@@CRLF'")

So is there some new level of strictness happening here ? Looking forward to yours or any members comments on this subject.

-Shawn

[ 14. January 2003, 06:51: Message edited by: Shawn ]

Lonkero

(KiX Master Guru)

2003-01-14 06:56 AM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

this is not higher truth, but...

as most of us know, there is this new thing called pre-tokenizing... or similar.

what my believes to the change in current problem is simple:
$= execute("$$var = '@CRLF'")
translates to
$var='
'

in parser.
now, see that line change there.
in 4.12 this was executed once occured, but I think one of the reasons why 4.20 is faster, is that it "compiles" the code before starting to execute.

thus, it seems to interpret the CRLF the same as LF.
isn't it just the same?
if you remove all CR's from your scripts manually (or with that spacer() I posted yesterday) you will get a script unreadable in notepad, but executable in kix.

anyway, I wanted to say something just to make sure no-one blames the execute of this.
hopefully ruud comes quickly and sorts this out.

cheers

[ 14. January 2003, 07:04: Message edited by: Lonkero ]

Sealeopard

(KiX Master)

2003-01-14 05:06 PM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

Actually, CRLF is not equal to CR and/or LF. The LF advances the cursor into the next line while the CR moves the cursor to the first column. The CRLF combination results in the cursor positioned in the first column of the next line.

I think the @CRLF macro should stay as two characters in a string up to the point where they are displayed in some kind of form (screen, messagebox, file).

Lonkero

(KiX Master Guru)

2003-01-14 05:21 PM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

mmm...
not sure what you mean with the similarity...
sure, that is different.
but, what I meant was that even though you write how many crlf compinations to file and read them with kix, it reads them as LF.
that is the current problem too.

if you do a script which has CRLF in var, like in shawns execution, kix translates them to LF.

so, the question currently is, should our scripts be changed to work by new tokenizer rules, or should the tokenizer be changed to be backward compatible.

the problem currently having is that anything inside function params, is processed.
so once again, in the execute, the @crlf is processed to be part of the string.
somehow now the new 4.20 code sees that and says, hey man, we don't need that CR (chr(13)) anymore.

I was confused at first... now I start to like this change more and more.

dunno...

Howard Bullock

(KiX Supporter)

2003-01-14 05:22 PM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

looking more like UNIX ... [Frown]

Howard Bullock

(KiX Supporter)

2003-01-14 05:25 PM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

I find it discomforting that

code:

$str = "$$var = " + '@CRLF'
$= execute("$str")

dies

ERROR : Error in expression.!
Script: c:\data\scripts\junk.kix
Line : 0

**DONOTDELETE**

(Lurker)

2003-01-14 05:39 PM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

2 separate issues, 2 replies:

1) Shawn indeed has found a (actually, the first) regression in 4.20. It's probably a minor issue, but a regression nonetheless, and it will be fixed in the final build.

2) The issue reported by Howard is actually expected behaviour. What happens is that the first part (the assignment) produces a 'mini-script' consisting of the following code:
"$var =
"
Clearly, this is invalid syntax. The Execute function will try to run this 'scriptlet', and produces the script error.

Hope this clarifies things.

Ruud

Richard H. Administrator

(KiX Supporter)

2003-01-15 11:18 AM

Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?

Just to close off Howard's post, the script should be:

code:

$str = "$$var = " + '@@CRLF'
$= execute("$str")

In *nix variables are expanded within double quotes, but not single quotes.
In KiXtart there is no differentiation - variables (and macros) are expanded in both double and single quoted strings.