I would like to trap syntax errors resulting from a "called" script so that I can log the error and then complete my parent script.

Any thoughts? Should this be suggested to Ruud?

[ 18 October 2001: Message edited by: Howard Bullock ]

I imagine you've thought of leaving their script to the very last so as to affect only them.

Maybe you could get MCA to write a callable KiXChecker to validate their script before you call it. Kludgy, I know, and you'd need to have some sort of revision tracking to avoid rechecking code that hadn't changed from the last time. Come to think of it, maybe Ruud could build that into KiX... something like a /Verify switch...

I'm starting to ramble... sort of cerebral diarrhea...

It is the first time we read something about "users make their own scripts".
Indeed kix32 doesn't have an error recovery mechanism, but with our
tool kixstrip you can pre-process it and you can verify the kixtart
code.
At the moment kixstrip doesn't return an errorlevel, when it encoun-
ters an error situation. We put something on our TO-DO list with a high priority.

A way of running your script without an abortion created by another script
can be by using the run or shell command.
A possible structure:

code:

---

;
; -first part of your script-
;
IF (Exist("c:\user.kix") = 1)
   SHELL '%comspec% /c kix32 c:\user.kix'
ENDIF
;
; -next part of your script-
;

---

By using kixstrip we are also using find command and GetFileSize function:

code:

---

;
; -first part of your script-
;
IF (Exist("c:\user.kix") = 1)
   ; - kixstrip is located somewhere on the server f.e. netlogon directory -
   SHELL '%comspec% /c kixstrip c:\user.kix nul                       >%temp%\zzzzz1.tmp'
   SHELL '%comspec% /c find /n /i "no errors found" %temp%\zzzzz1.tmp >%temp%\zzzzz2.tmp'
   IF (GetFileSize("%temp%\zzzzz2.tmp") < 30) THEN
      CALL "c:\user.kix"
   ELSE
      ? "Warning KIX: script of user contains errors."
   ENDIF
   del "%temp%\zzzzz?.tmp"
ENDIF
;
; -next part of your script-
;

---

code:

---

---------- c:\users.kix
[11] Informative KIXSTRIP:   no errors found.

---

btw: check the differences between file sizes with and without errors in your situation.
btw: kixstrip can only handle 8.3 filename.

Howard,
If you wanted to setup an INI file, logging users' script revision level, you could do a quick compare between the INI and reality. If they don't match, run the script through MCA's util. If you don't want the overhead in your logon, maybe you could have and admin script that watches for changes.
Still better would be if Ruud could make KiX pre-parse the script or do error recovery.

code:

---

dim $aArray[5]
For $iI = 1 to 6
   $iI $aArray[$iI] ?
Next

---

There is nothing intrinsically wrong with the code, but the out of bounds reference will cause a fatal error.

Being able to register a function which is called on a fatal error would be useful, with the reason for the failure passed as a paramater, or available through the @SERROR macro. The return value from the function could be used as a continue point in the script, so you could do something like:

code:

---

Break ON CLS
; Set fatal error handler
$sRestartPoint=""
if OnFatalCall("udfMyErrorFunction")
	"Cannot register OnFatalCall function" ?
	Exit 1
EndIf
...
...Corporate script section...
...
...
...
...
$RestartPoint="PostUserScript"
$sUserScript="H:\Logon.kix"
If Exist($sUserScript)
	CALL $sUserScript
EndIf
; Restart here if user script fails.
:PostUserScript
$RestartPoint=""
...
... More corporate script ...
...
...
...
Function udfMyErrorFunction($sReason)
   $=LogEvent(1,0,"Logon Script Failed due to: " + $sReason,@LSERVER)
   $udfMyErrorFunction=$sRestartPoint
EndFunction

---

<edit>
A null restart point would cause an abort as happens now.
</edit>

[ 19 October 2001: Message edited by: Richard Howarth ]

Maybe some ONERROR functionality to go with it.

You beat me to it ... we've already suggested an ON ERROR statement to Ruud and I know for a fact he's seen it - so the bug is (was) in his ear ... but all this talk of pre-parsing, etc makes me a little nervous ... seems a bit overkill no ?

A statement like this should cover this off:

ON ERROR statement

eg:

ON ERROR GOTO "ABORT"
ON ERROR GOSUB "ABORT"
ON ERROR ABORT()

To keep on going :

ON ERROR RESUME

To toggle this feature on/off:

ON ERROR 0 ; it's off
ON ERROR GOTO ABORT ; it's back on

You get the picture, basically a re-hash of the VB documentation ... the power of this approach comes from the fact that statement can be any old statement you want ... so this could work in Howards' situation and probably just about any other ...

Another idea (off-topic) was to build a feature that trapped a user hitting (^C) or killing a (logon) script ... something like this:

ON BREAK statement

This would be very handy (I think) ... would allow one to properly trap (and cleanup) one's script prior to exiting .. maybe even allow one to cancel the pending abort ...

-Shawn

I'm a relative newbie here, so forgive me if I suggest something that's already been suggested. If you count suggestions like votes, the more the merrier.

I don't see a quick pre-parser as unatainable but full error checking I think is. Error recovery is another matter. I fully ageree with you there bud.

We specially use a RUN '%comspec% /c kix32 user_script.kix'
to prevent users to influence the main script, but to prevent also
you - as network administrator - influence their script.
some possible problems:
- multiple usage of variable names
- open files
- script of user abort kix32.exe by his script
- unexpected changes take place by the client

Questions:

• what kind of things are your users doing with kixtart?
  - modifying registry keys?
  - removing policies?
  - changing printers?
  - changing desktop + startmenu settings?
  - .....
  
• how does you check users aren't use illegal activities with kixtart?
  
• what was the reason for this policy within your organisation? so we mention earlier: it is
  the first time users may and can do this kind of things.
  something what we can accept is that an user enter some information and an additional
  program will create automatically a piece of kixtart code which will run by your
  main script.
  
• what kind of problems you discover by users scripts?
  

Greetings.

btw: Shawn good points.

I have a set of published Global variables that they can use without gathering additional data. There is also a corporately control function library that provide things such as: 'MapDrive' and 'WriteLog'. These functions provide error checking, display data(if nec.), and logging. By using these functions all the scripts flow as one with the same look and feel that saves time and code.

If they happen to re-assign a value to a global variable they only screw themselve or those downstream from them for which they are responsible.

The user based scripts come last after all the corporate, regional, country, business unit, etc. stuff has already taken place.

These scripts involve a special user-based Citrix script that the user can configure his Citrix session as he sees fit. Since we have Citrix users from all over the globe hitting the same server farm, we can not always know what his local drive mapping may be. If the user asks, he can get assistance setting this up.

The user.kix that is stored in the user's home share executes last following the user where ever he goes and logs on. This is primarily used by the local LAN support and Help Desk staffs. They establish extra mappings to the software patches and drivers directories.

Most of the computer are locked down so that the user can not hurt himself. For those that have the ability and do hurt themselves, LAN support charges the user's department time & materials and simply kicks off a computer rebuild. Two hours later, everthing is back to normal. The user assumes the risk.

We provide the flexibility and to date it has worked quite well. I just want to improve it some more.

[ 21 October 2001: Message edited by: Howard Bullock ]