Page 1 of 2 12>
Topic Options
#142538 - 2005-06-28 04:12 PM Premature termination of nested loginscripts
OldFart Offline
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
#142539 - 2005-06-28 06:43 PM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
have you checked your scripts don't have missing quotes?
what if you comment the first call out?
or second?

and, if you really gonna use tokenization, you might wanna consider INCLUDE instead of call.
this way, you don't need to tokenize separately the support scripts/udfs but they are automatically tokenized inside the main kx-file.
at least I've learned to love that feature.
_________________________
!

download KiXnet

Top
#142540 - 2005-06-29 12:29 AM Re: Premature termination of nested loginscripts
Sealeopard Offline
KiX Master
*****

Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
And read the KiXtart documentation closely with regards to the limts of using INCLUDE!
_________________________
There are two types of vessels, submarines and targets.

Top
#142541 - 2005-06-29 06:04 PM Re: Premature termination of nested loginscripts
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
By all means do have a look at INCLUDE, as it will greatly reduce the number of network roundtrips in your logonscript. In your current script, CALL has to read every sub-script from the network. Using INCLUDE, you can reduce this to a single read of the entire logonscript.

Having said that, the sample code in your report should definitely work fine. It's indeed a good idea to check for mismatched quotes as well as check @ERROR and the eventlog.

Regards,

Ruud

Top
#142542 - 2005-06-30 09:46 AM Re: Premature termination of nested loginscripts
OldFart Offline
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
#142543 - 2005-06-30 05:09 PM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
scope of variables in included scripts is easy. it is the same as if you would have written the included script inside your including script.

what comes to the var scope of tokenized script, I shall take a simple example. (to proof it to myself too on the fly):
Code:

;the mainscript that calls
global $c
$c = "EXPLICIT TEXT ON GLOBAL SCOPE"

call "GetsCalled.kx"

get $


Code:

;the script that gets called "getsCalled.kix"
$c ?



no, tokenize them both separately and run the mainscript.
you see it works just like it would without tokenization.

now, if you have some variable dependency - intended or not - in some tokenized subscript, it may lead to unexpected behaviour in some situations, like complex string manipulation when the input is not what it should be.

anyway, if it is not too much asked, I think someone would like to see a failing called tokenized scripts code to hunt the cause down.
I could volunteer for that.

cheers,
younger fart
_________________________
!

download KiXnet

Top
#142544 - 2005-06-30 08:34 PM Re: Premature termination of nested loginscripts
Howard Bullock Offline
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")


_________________________
Home page: http://www.kixhelp.com/hb/

Top
#142545 - 2005-06-30 08:49 PM Re: Premature termination of nested loginscripts
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
You could siply leave off the extension from the script filename. KiX4.5 is coded to search first on the .kx if no extension is specified.
Quote:


Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>cd\KiX4.50rc3

C:\KiX4.50rc3>kix32 C:\KiXscripts\t1
This is pretokenized

C:\KiX4.50rc3>cd\KiX4.23

C:\KiX4.23>kix32 C:\KiXscripts\t1
This is not pretokenized

C:\KiX4.23>



_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

Top
#142546 - 2005-07-01 12:09 AM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
sure he could.
this is not the issue though.
the issue is that he has broken script and resolving what's wrong would be cool.

but otherwise, good point.
_________________________
!

download KiXnet

Top
#142547 - 2005-07-01 02:18 PM Re: Premature termination of nested loginscripts
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
In short: I've tried to repro this problem, but can't get it to fail.

If the problem persists, please post the sample scripts with which to reproduce the problem.

Regards,

Ruud

Top
#142548 - 2005-07-01 04:56 PM Re: Premature termination of nested loginscripts
OldFart Offline
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
#142549 - 2005-07-01 05:10 PM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
yes.
there was some issues with included files, well, but you don't include them any,right?
anyway, you should update and try with the gold to get the best success ratio.

and please let us know when you find what is the cause.
_________________________
!

download KiXnet

Top
#142550 - 2005-07-01 11:09 PM Re: Premature termination of nested loginscripts
Sealeopard Offline
KiX Master
*****

Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
It sounds more and more like a specific coding error in that particular script and not a general KiXtart problem.
_________________________
There are two types of vessels, submarines and targets.

Top
#142551 - 2005-07-04 09:06 AM Re: Premature termination of nested loginscripts
OldFart Offline
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
#142552 - 2005-07-04 03:39 PM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
last file in command line?
let me ask what type of command line you have?
I bet you do some "kix32 /t mainscript.kix all.kix the.kix sub.kix scripts.kix too.kix in.kix here.kix"

if it is so, stop that.

glad to hear final released you from the problem though.
_________________________
!

download KiXnet

Top
#142553 - 2005-07-04 04:24 PM Re: Premature termination of nested loginscripts
OldFart Offline
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
#142554 - 2005-07-04 05:51 PM Re: Premature termination of nested loginscripts
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
olderfart, I went ahead and asked from Ruud about this and indeed, the global space of the scripts is inherited by each script you add to the commandline.
so, if you tokenize them all in one commandline, the last file will have the global vars of all previous scripts.
at least, that's how I understood it.

now, the reason why include was succested still is there.
you don't give anything else but the mainscript as a parameter to kix /t and it will tokenize your entire script tree into kix-compiled kx-file.
and like ruud said before, it will be lot faster - and in fact should be smaller too (my note) - than if you use call and separately tokenize each script.
if not, there is either a bug, or some user "misbehavior" like in here.
_________________________
!

download KiXnet

Top
#142555 - 2005-07-05 09:03 AM Re: Premature termination of nested loginscripts
OldFart Offline
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
#142556 - 2005-07-05 09:17 AM Re: Premature termination of nested loginscripts
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
No problem that I see. Nothing wrong with using the CALL and in fact if I were in your place and / or an Admin that had to come in out of the blue to handle things on the fly, I think I would just steer clear of all the /t tokenized files. But hey, sounds like you have things under control which is good.
 

Top
#142557 - 2005-07-05 09:29 AM Re: Premature termination of nested loginscripts
OldFart Offline
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
Page 1 of 2 12>


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 557 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.075 seconds in which 0.027 seconds were spent on a total of 13 queries. Zlib compression enabled.