legacy-50096): Stopped processing.---seeing this error in TCL scripting - tcl

seeing this error message in TCL
XE> if {$host == "san-palladium-z1-01" || $host == "san-palladium-z1-02"} {db_download } else { exit }
invalid command name "1"
while executing
"1"
invoked from within
"if $::error == 1"
(procedure "error_check" line 2)
invoked from within
"error_check"
(procedure "db_download" line 2)
invoked from within
"db_download "
(file "xe_run.tcl" line 386)
ERROR (legacy-50096): Stopped processing.
XE>
info on error details
why am i seeing his legacy error

Related

How can I fix this error invalid command name "_o10 in NS2

You are missing the MIH / MIPv6 addition provided by ns-2.29-nist-mob-022707.tgz.This is for ns-2.29,but I usens-allinone-2.35.Is it the same procedure? Thanks!
This is my code link
https://drive.google.com/file/d/1Aan1OeAh5tIeDrt5MjgFTqvNSeahNWVy/view?usp=sharing
While running my tcl script for new protocol in NS2 it shows error as:
num_nodes is set 10
invalid command name "Agent/MIHUser/IFMNGMT/MIPV6/Handover/Handover1"
while executing
"Agent/MIHUser/IFMNGMT/MIPV6/Handover/Handover1 create _o216 "
invoked from within
"catch "$className create $o $args" msg"
invoked from within
"if [catch "$className create $o $args" msg] {
if [string match "__FAILED_SHADOW_OBJECT_" $msg] {
delete $o
return ""
}
global errorInfo
error "class $..."
(procedure "new" line 3)
invoked from within
"new Agent/MIHUser/IFMNGMT/MIPV6/Handover/Handover1"
invoked from within
"set handover [new Agent/MIHUser/IFMNGMT/MIPV6/Handover/Handover1]"
(file "bear2.tcl" line 177)
How can I modify it?

Reading Debugger output in Komodo IDE for Tcl Languare

I am trying to understand errors and exceptions in Tcl. I have written a small code as follows
proc Div3 {a b} {
return [Div2 $a $b]
}
proc Div2 {a b} {
return [Div $a $b]
}
proc Div {a b} {
if {$b == 0} {
error "Error generated by error" "Info String for error" 401
} else {
return [expr $a/$b]
}
}
if {[catch {puts "Result = [Div3 10 0]"} errmsg]} {
puts "ErrorMsg: $errmsg"
puts "ErrorCode: $errorCode"
puts "ErrorInfo:\n$errorInfo\n"
}
when I run this using tclsh.exe, the debugger output is shown as follows,
% tclsh error-file-1.tcl
ErrorMsg: Error generated by error
ErrorCode: 401
ErrorInfo:
Info String for error
(procedure "Div" line 1)
invoked from within
"Div $a $b"
(procedure "Div2" line 2)
invoked from within
"Div2 $a $b"
(procedure "Div3" line 2)
invoked from within
"Div3 10 0"
However, when I run the same using tclsh.exe via Komodo IDE, I am getting the debugger output as follows
ErrorMsg: Error generated by error
ErrorCode: 401
ErrorInfo:
Info String for error
invoked from within
"DbgNub_uplevelCmd 1 $cmd"
invoked from within
"Div $a $b"
invoked from within
"DbgNub_uplevelCmd 1 $cmd"
invoked from within
"Div2 $a $b"
invoked from within
"DbgNub_uplevelCmd 1 $cmd"
invoked from within
"Div3 10 0"
invoked from within
"DbgNub_uplevelCmd 1 $cmd"
invoked from within
"DbgNub_Do 0 {1 17 {249 27}} {puts "Result = [DbgNub_Do 1 {1 17 {265 9}} {Div3 10 0}]"}"
I can understand the debugger output from tclsh.exe but unable to interpret the debugger output from Komodo IDE.
especially, I am unable to understand DbgNub_Do 0 {1 17 {249 27}} {puts "Result = [DbgNub_Do 1 {1 17 {265 9}} {Div3 10 0}]"} what are the number shown in the lists (i.e {1 17 {249 27}}) and DbgNub_uplevelCmd 1 $cmd and DbgNub_Do
Thanks in advance
All the DbgNub_ commands mentioned in the stack trace are Komodo's extra debugging instrumentation (hiding them in the stack trace is theoretically possible, but messy and the instrumentation obviously doesn't actually do it). Generally, you probably ignore those commands as they're not going to be there when you deploy.
If we ignore the DbgNub_uplevelCmd bits, we get:
Info String for error
invoked from within
"Div $a $b"
invoked from within
"Div2 $a $b"
invoked from within
"Div3 10 0"
invoked from within
"DbgNub_Do 0 {1 17 {249 27}} {puts "Result = [DbgNub_Do 1 {1 17 {265 9}} {Div3 10 0}]"}"
That's recognisably similar to the standard trace except for the lack of line number information (and the DbgNub_Do, which is obviously instrumenting the code inside the catch directly).
Generally, Tcl's result status consists of:
A result code. This is TCL_OK (= 0) on success of a piece of code, TCL_ERROR (= 1) if an exception was thrown, and a few other values for other things (TCL_RETURN, TCL_BREAK and TCL_CONTINUE). Those names are defined at the C level.
A result value that is stored in the interpreter. In ancient versions of Tcl this was a simple string, but it's been a reference-counted typed value for over 20 years. (Tcl does have a type system. It's just very different from every other language's in that strings are the supertype of all other types.)
A result dictionary that contains additional information. Standard entries (it's possible to define your own too) in this are:
The error information, a.k.a stack trace that gets written to the errorInfo global to support old code. Only really meaningful for errors.
The error code, a machine readable exception descriptor that gets written to the errorCode global to support old code. Again, only really meaningful for errors.
The error line. The bit that's used to generate the number in the message (procedure "Div" line 1) and so on.
The level, which is used by return to do multi-level returns.
There's some other bits and pieces that only kick in in a few cases (such as when a try's finally clause throws an exception when the body of the exception threw, a gnarly case in lots of languages).

Why is ::cmdline::getoptions throwing an error?

Why does the following code:
#!/usr/bin/env tclsh
package require cmdline;
set options {{d.arg "" "destination directory"}}
set usage ": $::argv0 \[options] filename ...\noptions:"
set params [::cmdline::getoptions ::argv $options $usage]
throw the following error upon execution of ./main.tcl -help?
main : ./main.tcl [options] filename ...
options:
-d value destination directory <>
-help Print this message
-? Print this message
while executing
"error [usage $optlist $usage]"
(procedure "::cmdline::getoptions" line 15)
invoked from within
"::cmdline::getoptions ::argv $options $usage"
invoked from within
"set params [::cmdline::getoptions ::argv $options $usage]"
(file "./main.tcl" line 8)
It should display the usage information, but I didn't expect the error afterwards. Did I do something wrong?
From what I understand from the docs (emphasis mine):
The options -?, -help, and -- are implicitly understood. The first two abort option processing by throwing an error and force the generation of the usage message, whereas the the last aborts option processing without an error, leaving all arguments coming after for regular processing, even if starting with a dash.
using -help or -? will always throw an error.
Further down in the docs you can see an example where try { ... } trap { ... } is being used in conjunction with ::cmdline::getoptions, which might be how you might want to do it:
try {
array set params [::cmdline::getoptions ::argv $options $usage]
} trap {CMDLINE USAGE} {msg o} {
# Trap the usage signal, print the message, and exit the application.
# Note: Other errors are not caught and passed through to higher levels!
puts $msg
exit 1
}

Tcl Error: can't rename to "::sha2::SHA256Init": command already exists

I'm having issues with the pki library while using sha256. Here's is the following line of code that I am having issues with:
package require pki
set $signature "whatever"
set $keydata "some real 256 RSA key"
set key [::pki::pkcs::parse_key $keydata]
set sig [some_class::base64_url_encode -input [::pki::sign $signature $key sha256]]
And here is the following error message I get:
can't rename to "::sha2::SHA256Init": command already exists
while executing
"rename ::sha2::${c}-${key} ::sha2::$c"
(procedure "SwitchTo" line 38)
invoked from within
"SwitchTo $e"
("foreach" body line 3)
invoked from within
"foreach e [KnownImplementations] {
if {[LoadAccelerator $e]} {
SwitchTo $e
break
}
}"
(in namespace eval "::sha2" script line 3)
invoked from within
"namespace eval ::sha2 {
variable e {}
foreach e [KnownImplementations] {
if {[LoadAccelerator $e]} {
SwitchTo $e
break
}
}
..."
(file "/usr/local/naviserverXXXX/lib/tcllib1.15/sha1/sha256.tcl" line 820)
invoked from within
"source /usr/local/naviserverXXXX/lib/tcllib1.15/sha1/sha256.tcl"
("package ifneeded sha256 1.0.3" script)
invoked from within
"package require sha256"
(procedure "::pki::sign" line 16)
invoked from within
"::pki::sign $signature $key sha256"
Then I tried doing this:
catch {namespace delete ::sha256}
package require pki
set $signature "whatever"
set $keydata "some real 256 RSA key"
set key [::pki::pkcs::parse_key $keydata]
set sig [some_class::base64_url_encode -input [::pki::sign $signature $key sha256]]
And now I get a different error saying that sha256 is being loaded from a different library:
can't rename to "::sha2::SHA256Init": command already exists
while executing
"rename ::sha2::${c}-${key} ::sha2::$c"
(procedure "SwitchTo" line 38)
invoked from within
"SwitchTo $e"
("foreach" body line 3)
invoked from within
"foreach e [KnownImplementations] {
if {[LoadAccelerator $e]} {
SwitchTo $e
break
}
}"
(in namespace eval "::sha2" script line 3)
invoked from within
"namespace eval ::sha2 {
variable e {}
foreach e [KnownImplementations] {
if {[LoadAccelerator $e]} {
SwitchTo $e
break
}
}
..."
(file "/web/dev/project-directory/httpd/lib/tcllib1.15/sha1/sha256.tcl" line 820)
invoked from within
"source /web/dev/project-directory/httpd/lib/tcllib1.15/sha1/sha256.tcl"
("package ifneeded sha256 1.0.3" script)
invoked from within
"package require sha256"
(procedure "::pki::sign" line 16)
invoked from within
"::pki::sign $signature $key sha256"
I've tried restarting the server and the same error keeps on popping up. Is there a problem with the server loading and not booting with the correct library dependencies?

What's the difference between return -code error and error

What is actually the difference between raising an exception in TCL via return -code error ...and error ...? When would one be used instead of the other?
The error command produces an error right at the current point; it's great for the cases where you're throwing a problem due to a procedure's internal state.
The return -code error command makes the procedure it is placed in produce an error (as if the procedure was error); it's great for the case where there's a problem with the arguments passed to the procedure (i.e., the caller did something wrong).
The difference really comes when you look at the stack trace.
Here's a (contrived!) example:
proc getNumberFromFile {filename} {
if {![file readable $filename]} {
return -code error "could not read $filename"
}
set f [open $filename]
set content [read $f]
close $f
if {![regexp -- {-?\d+} $content number]} {
error "no number present in $filename"
}
return $number
}
catch {getNumberFromFile no.such.file}
puts $::errorInfo
#could not read no.such.file
# while executing
#"getNumberFromFile no.such.file"
catch {getNumberFromFile /dev/null}
puts $::errorInfo
#no number present in /dev/null
# while executing
#"error "no number present in $filename""
# (procedure "getNumberFromFile" line 9)
# invoked from within
#"getNumberFromFile /dev/null"