I appear to be getting a problem with scripting in 3.11 that didn’t appear to happen with previous versions (that said, I haven’t actually confirmed that this is true! i.e. I haven’t rolled back the OS level).
When I use a script such as:
:if ([/tool fetch address=$server port=$port dst-path=$pathname src-path=$serverpath mode=http] = 0) do= {
:log error “FTP ERROR - Update NOT retrieved”
} else= {
:log info “File retrieved from server”
}
IF the file exists, the script logs the “File retrieved…” message into the log. BUT If the file DOESN’T exist, the script logs nothing, and (in this case) terminates on the console with:
status: failed
failure: 404 /update.rsc
This appears to be a scripting engine issue (or I’m missing some vital information ), as this also happens with this same sort of code :
/system script run CONFIG
Again, if the script exists, no problem, but if it is missing, then:
interrupted
invalid item number
I appreciate I should ‘test’ to see if things exist before executing them, but this isn’t always possible (i.e. with fetch)
Am I missing something? Or is this a bug that has been introduced into 3.11?
And if it is, can I have a free L6 license for finding such a significant bug?
As I said, I haven’t rolled back to test this, but I was pretty sure that I had tested it when I wrote the script initially (although I am not 100% sure)
But, regardless of this, surely this is still a bug!!! If this is a ‘feature’ of ROS, then this must be the first scripting language I have used in years that doesn’t allow you to trap this sort of error. As I said it happens with ‘fetch’, and also ‘run’, and I assume any other [/…] command that fails.
I find that the documentation on scripting is VERY limited, particularly with regard to 3.x (and the differences when compared to 2.x), would you know if there is any ‘trap’ type functionality of the ROS scripting engine i.e. something like:
nerror do= {:log error “THE SCRIPT TERMINATED WITH AN ERROR - [” . $errorline . “:” . $errorcol . “]”}
The reason I ask, is that even with full debuging, the ‘fetch’ issue doesn’t report any ‘status’ info, so when checking to see if a download has completed you don’t actually know (via the log) if the script is running or still downloading.
I suppose I could set a global variable to say “It’s running”, then have a scheduled script to check to see if the global variable is set, and the ‘fetch’ script is still running, and if not, to log an error to say the script unexpectedly terminated. BUT this appears very complex to achieve this sort of functionality.
Maybe I’ll do this as a work-around, but think that MT should see this as a bug!
), as this also happens with this same sort of code :
nerror do= {:log error “THE SCRIPT TERMINATED WITH AN ERROR - [” . $errorline . “:” . $errorcol . “]”}