SAPIEN Forums

An option to leave script names unchanged in a script package. That way if your using things like Wscript.ScriptName you can actually rely on it coming back with the intended name and not a randomly generated script name. Along with that option could be an optional overwrite existing files.

For example, I have test.vbs which relies on a supporting ini file named test.ini. When I script for this I will have it get the filename (without extension) of the running vbs which is "test" and add a .ini extension to find the supporting "test.ini". Currently when the script is packaged this functionality breaks because the script name is randomly generated, but the ini file name is retained because it's in the data files area.

This is just one example, but I can think of quite a few other things that would benefit from having these options added.Travis.Golliher@aps.com2008-02-05 11:05:27

Unfortunately there is a reason it uses random names.

If you run multiple instances of a packaged script using the external engine (CScript or WScript) each instance needs its own copy of the script.

Alex

Not sure I follow you.
Once the script has been loaded into memory by cscript or wscript the vbs file can be deleted. So if I ran the package the first time, and it's still running when I run it the second time it would overwrite the first copy of the script and run it regardless and both packages would finish just fine. This is because it's already loaded in memory by cscript or wscript.

It must be more complicated than that?

It is. If you're using WScript/CScript, the script file has to remain on-drive for the duration of execution. WScript and CScript don't load the entire script into memory for execution, and they can lock the file so that another process wouldn't be able to access it properly.

So, if you ran Package A and it wrote the scripts, and then ran it again, the second instance might still be running when the first finished and tried to delete the files.

In essence, the random names keep two instances of the package from stomping on one another.donj2008-02-05 11:49:05

Why not tag each package with a GUID and not allow more than one instance of the package to run when the person opts to leave the script name intact? Just note it in the docs as a known limitation. I'd rather have the ability with that caveat than not have it at all.

We'll certainly let the dev team take it under advisement! They do try not to make things overly complex, and I'm sure you know folks' track record for reading the docs , but perhaps they'll come up with something elegant in a future build.