#79430 - 2003-01-14 06:47 AM
4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
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 ]
|
Top
|
|
|
|
#79433 - 2003-01-14 05:21 PM
Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Lonkero
KiX Master Guru
Registered: 2001-06-05
Posts: 22346
Loc: OK
|
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...
_________________________
!download KiXnet
|
Top
|
|
|
|
#79434 - 2003-01-14 05:22 PM
Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
looking more like UNIX ...
|
Top
|
|
|
|
#79435 - 2003-01-14 05:25 PM
Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
I find it discomforting that code:
$str = "$$var = " + '@CRLF' $= execute("$str")
dies
ERROR : Error in expression.! Script: c:\data\scripts\junk.kix Line : 0
|
Top
|
|
|
|
#79436 - 2003-01-14 05:39 PM
Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Anonymous
Anonymous
Unregistered
|
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
|
Top
|
|
|
|
#79437 - 2003-01-15 11:18 AM
Re: 4.20 RC1 - Problem with @CRLF & Strings & Execute ?
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
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.
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 507 anonymous users online.
|
|
|