It has something to do with how Kix32.exe handles arguments.
"Kix32 script1 script2 script3" is valid, and will cause the 3 scripts to be executed in sequence. If "script2" is actually an argument, and isn't processed/understood by Script1, then kix32 assumes it is a script, and complains when it can't find it. Exits with status 2 (file not found).
You can circumvent this by exiting Script1 with QUIT 0 instead of EXIT 0. This terminates the current and all following scripts. Not always a clean or convenient process, though. The true fix is to make sure Kix treats your script args properly, passing them to the script and not using them directly.
I've found it's really important to use "--" or "//" to identify kix SCRIPT arguments. When Kix sees the leading "-" or "/", it knows not to process it as a script name. The need to double the argument identifier prevents kix from seeing "-download" as "-d" and invoking debug mode! Remember, kix32 runs and interprets the command line FIRST. It accepts "unadorned" args as script names, and anything beginning with "-" or "/" as a potential modifier. It will use them itself, even though it passes all the args to your script. Thus, you often get unwanted results.
Bottom line
"Kix32 MyScript filename" will usually fail because "filename" can't be found, or isn't a script.
"kix32 MyScript --f:filename" will work, because kix32 knows to pass it to the script. Of course, you need to verify the "--f:" part and Split on the ":" to get the filename. More up-front work, but much higher reliability.
"kix32 MyScript -download" will invoke kix debug mode, while
"kix32 MyScript --download" will run normally.
Hope this helps.
Glenn
_________________________
Actually I
am a Rocket Scientist!
