|
|
|||||||
This is a return to a post from July '04 where earlier versions were noted as not returning a value on @LOGONMODE. I've experimented with this again and it also exists in 4.23 (at least it does in my environment!). Just in case anyone was wondering why you'd use it, it's really useful for debugging where you want to ensure you can test production changes against the latest release area i.e. if LOGONMODE isn't '1' we're debugging and therefore pull the sub-scripts and settings from the over there (rather than one of 60+ domain controllers). Am I unique in seeing this, or is it an accepted fault? Thanks Matthew |
||||||||
|
|
|||||||
you may be the only one trying to use it |
||||||||
|
|
|||||||
I can confirm it has been broken on all builds after 4.10, upto and including 4.5b2. |
||||||||
|
|
|||||||
there is no such build as 4.5b2 |
||||||||
|
|
|||||||
Right you are.. KiXtart 2010 Alpha 2... build 144 |
||||||||
|
|
|||||||
hmm... was that 2010 decided codename? well, anyways. what I ment was that it's 4.5a2 not b. |
||||||||
|
|
|||||||
Not a fix for the problem, but here is how I deal with the development / test issue: Code: $=SetOption("Explicit","ON") ; Sanity check for variable names. As you can see, I do it by setting variables on the command line. $__DEVELOPMENT is a boolean, set to true if I want the script to run the dev version. If it is set the script will try to find a copy of itself with the same name in the dev tree, and if it finds one it will launch that version instead ($__DEVELOPMENT is reset to ensure that the dev script doesn't call itself in an endless loop!). In my environment $__DEVELOPMENTDIR is set to a subdirectory of @HOMESHR which allows different staff to try things out without fear of clashing. $__ROOT can be set to force the currently script to look for support libraries and files other than in the directory that it was started in. $__DEBUG if set outputs debugging information. The higher the value that it is set to the more debugging output. The benefit of using variables like this is that they can be set on an individual login, and you can test the script within the live environment without affecting other users. |
||||||||
|
|
|||||||
...I feel isolated and alone with my broken function (which also returns me....nothing).... <sigh> |
||||||||
|
|
|||||||
Thanks for the steer on how you manage your debugging process Richard - it's a nice approach. Looks like I'll have to rethink this... Matthew |