#142538 - 2005-06-28 04:12 PM
Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
Hello friends of KIX !
I'm maintaining a nested set of loginscripts and experience premature (but error-free) script terminations during testdrive with KIX 4.50 RC1. From 4.20 to 4.23 everything worked fine. The scenario:
Startup of loginscript package via batchfile:
KIX32_450rc1.EXE pre\Starter.kix dep\Department.kix post\Finish.kix
All three scriptkompoments contain various CALLs to other script, like:
call 'sub\Constants.kix' call 'sub\Mappings.kix' call 'sub\Printer.kix' ... etc. You get the idea.
In order to prepare for the use of pretokenized scripts (great feature !) I modified the CALLs to:
global $suffix $suffix = '.kix' ; see following text !
call 'sub\Constants' + $suffix call 'sub\Mappings' + $suffix call 'sub\Printer' + $suffix
In real life the value of $suffix is dynamically set to '.kix' or '.kx' depending on the KIX version as given by @kix. So I can run the scripts using any KIX version and can dynamically switch between plain text and pretokenized scripts.
Well, KIX 4.50 RC1 with pretokenized scripts terminates silently at the 2nd executed CALL. No error message, no return code set. Single-stepping through the CALLs indicates that the 1st CALL doesn't execute the called scriptcode, stepping over or into the 2nd CALL terminates the whole script run, as seen when run without single-stepping.
Switch back to KIX 4.2x (and to .kix suffix, of course) and everything works as expected.
What goes wrong?
Thanks a lot for any help and/or suggestions.
OlfFart
|
Top
|
|
|
|
#142542 - 2005-06-30 09:46 AM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
Thank you Lonkero, sealeopard and Ruud for your suggestions. I finally managed to make my scripts run. The short essence is: I enthusiastically misused the pretokenization feature. My fault, sorry.
And now the details: I changed my code to enable switching between plain text/pretokenized script variants without editing code. I defined the desired suffix on the command line at startup:
KIX32_540rc1.EXE pre\foo.kix dep\bar.kix post\baz.kix $SUFFIX=".kx"
The CALLs are built like:
call 'sub\whatever' + $suffix
Now I could alternativly run both script variants plain/tokenized only by changing the command line. The plain text version worked perfectly. This was no surprise, as it worked before with KIX 4.1x to 4.2x. The pretokenized variant terminated as described above. Since I didn't change code to switch between variants this proves the code to be syntactically (unmatched quotes) and structurally (variable scope boundaries) sane. Obviously, there was something specifically wrong with the tokenization.
Thinking about INCLUDE and its implications for scope of variables, I finally asked myself "How does a pretokenized script know about GLOBAL variables defined by other scripts run before it ? How does it handle references to unknown variables ?". I'm still thinking about how it works, but in my case it just doesn't know and that makes it crash.
I use some scripts do do several maintenance tasks during development (backup older versions of edited files, prettifying, upload of touched files to the replication directory, etc.). Think of it as a "makefile". I added one command to freshly pretokenize touched files - but, and this is the flaw: each file is handled parted from the ohers, like:
KIX32_540rc1.EXE pre\foo.kix /t KIX32_540rc1.EXE dep\bar.kix /t KIX32_540rc1.EXE post\baz.kix /t
Poor kaz.kx, how should it handle references to global Vars defined in foo.kx and bar.kx ? I did a complete coherent build using a veeeery long command line:
KIX32_540rc1.EXE pre\foo.kix dep\bar.kix post\baz.kix .... etc ... /t
And now it works fine. Obviously, the pretokenized files undermine the "explicit" directive. Crossreferences to variables which are not available during the pretokenization run are not warned about. They just lead to unexpected behaviour. Sorry that I missed to recognize this earlier and to annoy you for my pilot error. On the other hand, this effect is a major drawback ...
Regarding the INCLUDE suggestions, I don't think they fit to my script structures. My approach uses distinct and mostly independent sub-scripts, which can be glued together by a calling script. Local variables do not interfere between thes sub-scripts. Using INCLUDE and pretokenizing the whole bunch naturally solves the problem of unresolved references, but makes the several sub-scripts act in one variable scope. Right ? This undermines my rigid script boundary policy.
I can chatter endless about this stuff, but I think I should stop my verbose babble now ...
Can you give me some pointers to technical detail documents about the pretokenization feature? How are references to external variables handeled? What about scope of variables in INCLUDEd scripts?
I'm still courious about it.
Greetings
OldFart
|
Top
|
|
|
|
#142544 - 2005-06-30 08:34 PM
Re: Premature termination of nested loginscripts
|
Howard Bullock
KiX Supporter
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
|
If you elect not use INCLUDE and still want to call scripts explicitly try something like this.
Code:
Function CallScript2($ScriptFile) dim $ScriptFile If Exist($ScriptFile) WriteLog("Executing " + $ScriptFile) $Indent = "" + $Indent + " " Call $ScriptFile WriteLog ("Returned from " + $ScriptFile) $Indent = left($Indent, len($Indent) - 3) Else ;WriteLog ("Does Not Exist: '" +$ScriptFile + "'") Endif Endfunction
CallScript2($Path + "\" + $element + %LOCALRUN% + ".kix")
|
Top
|
|
|
|
#142548 - 2005-07-01 04:56 PM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
I built a really convoluted test script scenario involving 6 files with sub-script calls, function definitions and -calls, global and local variables and failed to synthesize the problem. Everything works rock solid. In that sense: Yes I agree, I can't reproduce the problem either. But my productive loginscripts still fail under the specific circumstances I described above. Absolutely weird, since the overall structure of my testscript closely follows the genaral structure of my real-life scripts.
Currently I'm doing the opposite approach. I'm actively thinning out the failing scripts. The idea is to move them into the direction of the working synthetic test scripts until they don't abort. Somewhere on this way the failure must disappear - if there isn't magic involved it it.
Is the final 4.50 identical to RC1 ? In other words: Are there any differences that may influence my hunt for the problem ? On monday I will try final 4.50 with my real life scripts. I'm absolutely excited to see the result.
I will notify you of any research findings. Stay tuned and thanks to all for their input !
Greetings
OldFart
|
Top
|
|
|
|
#142551 - 2005-07-04 09:06 AM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
Monday morning 8:00 h and I'm back again. Retokenized my real-life scripts separately as described as my pilot error (see above). Using KIX 450RC1 the script abortion was back again. Replaced 450RC1 with 450FINAL, pretokenized everything separately again, uploaded to the server, logged in.
Believe it or not - no abortion. Works really nice. Very very good. Great. Thanks Ruud.
Lonkero: You are right. I didn't use INCLUDE. But when comparing the separately pretokenized files vs. all-in-on-run pretokenized there are significant size differences in the resulting .kx files. The all-in-one-run pretokenized .kx files are MUCH larger (exept the first one in the pretokenization command line, which does not include pretokenized code from other script files, obviously). The grow in size expands - the last file in the command line being the fattest one, obviously containing pretokenized code included from all other files. This is described as an intended effect of include & pretokenize. From my files sizes I deduce that the same external code inclusion takes place in my case - even though I don't use the INCLUDE statement. I could reproduce this behaviour with my synthetic test scripts which do not use INCLUDE too. This explains why a different script behaviour between individually pretokenized files vs. all-in-on-run pretokenized files is basically possible. Somehow this worked wrong for my scripts in the one case and fine for the other case. Fixing the INCLUDE issues from 450RC1 to 450FINAL also cured my specific problem. Now I can benefit from pretokenization AND have small .kx files resulting from a individual pretokenization of each single script source file ... superb !
sealeopard: As for a suspected coding error - the scripts did work in previous KIX versions, in 450RC1 when using .kix, and in 450RC1 using .kx when pretokenizing all scripts in one run. The error was specific to a 450RC1 pretokenization of individual files. And this issue disappeared with final 450.
I'm really happy now. Good start of the week.
Thank you all for your support.
OldFart
|
Top
|
|
|
|
#142553 - 2005-07-04 04:24 PM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
You don't need to ask or bet. As I described in my lengthy 30/06/2005 posting:
> I did a complete coherent build using a veeeery long command line: > KIX32_540rc1.EXE pre\foo.kix dep\bar.kix post\baz.kix .... etc ... /t > And now it works fine.
I disliked that brute-force mass pretokenization very much - at least for its result with exploding file sizes. With final 4.50 the individual pretokenization works perfect. I immediately switched back to my previously used makescript technique with single-file pretokenization for touched (aka: freshly edited) files as described a few lines earlier in the mentioned posting.
Good news: I assigned the pretokenized scripts to some unsuspecting but generally alert volunteers in my department and until now I haven't heard of any loginscript misbehaviour. ;-)
OldFart
|
Top
|
|
|
|
#142555 - 2005-07-05 09:03 AM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
Regarding the name space inclusion: Your callback to Ruud nicely confirms my empirical findings. Thank you.
Concerning my non-usage of INCLUDE: Let me explain.
I have to maintain 74 loginscripts. They reflect 74 departments of my company, each one has a unique dedicated loginscript. Don't ask about the irritating number of departments or the dedication of separate scripts - it is the way it is. Politics, OK ? As a way of dealing with this ancillary conditions, I did the following: Each script just contains a set of CALLs to script modules delivering specific functionality (let us assume a [definitly too] simple example: mapping a network share). I have 43 modules yet (12000+ effective code lines), most of them generic ones which can be parameterized by INI-files, but this is a different story ...
When changes to departmental loginscripts are requested, lets say they want a functionality to be added, I just pick one of those modules and make a CALL to it. Sometimes I have to implement a new module for this but most of the time I have a fitting one ready for a CALL. Done. Or I just remove a CALL for the opposite case (they don't want a specific funtionality any more for their department). Done. For general changes to a specific functionality (let us assume for the above example: change in the network share mapping logic) I edit the corresponding module. Done. For this whole scenario the new pretokenization feature just requires a pretokenization run for the changed departmental/sub-script file. Done. Straightforward, simple, maintainable for other guys when I'm at vacation ... this an absolute must, take my word for it.
Now consider what happens if I change this to using INCLUDE instead. A change of a departmental script just requires retokenization of this specific script. Easy. A change in a CALLed (sorry: INLUDEd) script requires retokenization of any departmental script which references that sub-script. This is a call for headaches. To make this stuff work automatically I would have to build some makefile dependency tree for departmental/sub-script references and have to use this for automated rebuilds of relevant files. But even with this automatism there is trouble ahead: adding/removing CALLs (read: INCLUDEs) without changing the makefile accordingly will lead to disaster. This is an additional administrative task for script maintenance that will predictably fail sometime, by all means when I'm on vacation. Again, take my word for it. I am definitly not fond of being called in my holidays because of mysteriously failing loginscripts. This kind of trouble is what I want to avoid desperately. Therefore I need to keep the script environment complexity at a foolproof level.
Did this explanation helped in understandig why I prefer CALLs instead of INCLUDEs ?
OldFart
|
Top
|
|
|
|
#142557 - 2005-07-05 09:29 AM
Re: Premature termination of nested loginscripts
|
OldFart
Fresh Scripter
Registered: 2005-06-28
Posts: 13
Loc: Marburg, Hessen, Germany
|
> I think I would just steer clear of all the /t tokenized files
This would lower the complexity even more, which is a GOOD THING. But alas, I do some software installation in some loginscripts. This requires administrative rights and therefore I exec "runas" with some nasty tricks to cover the login & password. Therefore the additional script obfuscation using pretokenization comes handy ...
Besides, the pretokenized files are half the size of the corresponding clear-text files, which is a GOOD THING too ...
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 557 anonymous users online.
|
|
|