info option ?arg arg ...?
- info args procname
- info body procname
- info class subcommand class …
- info cmdcount
- info commands ?pattern?
- info complete command
- info coroutine
- info default procname arg varname
- info errorstack
- info exists varName
- info frame ?number?
- info functions pattern
- info globals ?pattern?
- info hostname
- info level ?number?
- info library
- info loaded ?interp?
- info locals ?pattern?
- info nameofexecutable
- info object subcommand object …
- info patchlevel
- info procs ?pattern?
- info script ?filename?
- info sharedlibextension
- info tclversion
- info vars ?pattern?
http://purl.org/tcl/home/man/tcl8.5/TclCmd/info.htm
What are some common uses of the info command in day to day programming?
With info, you can find out about your tcl environment. For example
In response to a question about finding a way to tell who called a particular proc, Bruce Hartweg wrote on news:comp.lang.tcl (in message 3B157767.A720881E@raytheon.com ):
And Will Taylor writes:I find a backtrace useful -- putting these two stmts in the proc in question:
AM A common idiom that I use:
With info, you can find out about your tcl environment. For example
proc ls {{ns ::} {all no}} {
puts "namespace $ns"
foreach child [namespace children $ns] {
if { "all" == $all } {
list $child all
} {
puts "namespace $child"
}
}
set pat "[set ns]::*"
foreach proc [info procs $pat] {
puts "proc $proc"
}
foreach var [info vars $pat] {
if { [array exists $var] } {
puts "array $var"
} {
puts "variable $var"
}
}
}now what would be a good way of extending that to list the significant symbols in interps?See tkinspectIn response to a question about finding a way to tell who called a particular proc, Bruce Hartweg wrote on news:comp.lang.tcl (in message 3B157767.A720881E@raytheon.com ):
# quick tester:
proc who_called {} {
puts "I was called from '[lindex [info level -1] 0]' - but first call was to
'[lindex [info level 1] 0]'"
}
proc a {} {who_called}
proc b {} {who_called}
proc c {} {who_called}
proc d {} {a}
proc e {n} {$n}
# end
Output:
% a
I was called from 'a' - but first call was to 'a'
% b
I was called from 'b' - but first call was to 'b'
% c
I was called from 'c' - but first call was to 'c'
% d
I was called from 'a' - but first call was to 'd'
% e a
I was called from 'a' - but first call was to 'e'
% e b
I was called from 'b' - but first call was to 'e'
% e c
I was called from 'c' - but first call was to 'e'
% e d
I was called from 'a' - but first call was to 'e'And Will Taylor writes:I find a backtrace useful -- putting these two stmts in the proc in question:
set backtrace ""; getBackTrace backtrace puts stderr "<the-proc-in-question>: `$backtrace'"Here is the backtrace proc:
proc getBackTrace { backTraceRef } {
upvar $backTraceRef backTrace
set startLevel [expr {[info level] - 2}]
for {set level 1} {$level <= $startLevel} {incr level} {
append backTrace "[lindex [info level $level] 0] => "
}
}Note also that the Bag of algorithms makes a couple of mentions of backtracing, and even has other uses of [info ...].AM A common idiom that I use:
set scriptdir [file dirname [info script]]so that I know where my other scripts or data files that need to be sourced/read are located.Another use: detect the difference between running the script on its own or as a package:
if { [file tail [info script]] == [file tail $::argv0] } {
# The script is running on its own!
}There is one particular caveat: the command will return an empty string when it is called in an event handler - then there is no script being "sourced" anymore! So, save the result when you need it later on (that is: later on in the process, not later in the source file).