tclvars(3tcl)

πŸ’– tclvars β€” the Tcl variables glow-up πŸ’–

okay bestie, welcome to tclvars from the Tcl Built-In Commands manual β€” yes it's a weird name for a page about a whole squad of variables, but here we are, we're slaying anyway 🫢


🌸 NAME 🌸

argc, argv, argv0, auto_path, env, errorCode, errorInfo, tcl_interactive, tcl_library, tcl_patchLevel, tcl_pkgPath, tcl_platform, tcl_precision, tcl_rcFileName, tcl_traceCompile, tcl_traceExec, tcl_version β€” literally all of these are Variables used by Tcl ✨


πŸŽ€ DESCRIPTION πŸŽ€

so here's the tea: the Tcl library creates and manages these global variables automatically. She's got it handled, you don't need to do anything πŸ’…

except where it says otherwise below, you should treat these as read-only. Like, hands off, no cap β€” application-specific code and users are not meant to be writing to them πŸ™ˆ

✨ auto_path ✨

if it's set, it must contain a valid Tcl list giving directories to search during auto-load operations (and that includes for package index files when you're using the default package unknown handler πŸ‘€).

this variable gets initialized during startup to contain, in this exact order:

  1. the directories listed in the TCLLIBPATH environment variable
  2. the directory named by the tcl_library global variable
  3. the parent directory of tcl_library
  4. [file dirname [file dirname [info nameofexecutable]]]/lib
  5. the directories listed in the tcl_pkgPath variable

if you wanna add more places to look for files and package indices, the correct move is normally to lappend onto this variable. that's the vibe. πŸ‘‘

there are also additional variables relating to package management hanging around β€” more details are listed in the VARIABLES section of the library manual page πŸ“š


πŸ¦‹ env πŸ¦‹

this one is an array, maintained by Tcl, and its elements are the environment variables for the process. iconic.

  • reading an element β†’ returns the value of the corresponding environment variable βœ…
  • setting an element β†’ modifies the corresponding environment variable, or creates a new one if it doesn't already exist πŸ†•
  • unsetting an element of env β†’ removes the corresponding environment variable πŸ—‘οΈ

changes to the env array will affect the environment passed to children by commands like exec πŸ‘Ά

⚠️ if the entire env array is unset, then Tcl stops monitoring env accesses and will not update environment variables anymore. so like… don't do that unless you mean it 😭

Windows girlies, listen up πŸͺŸ: the environment variables PATH and COMSPEC in any capitalization get converted automatically to upper case. for instance, the PATH variable could be exported by the operating system as β€œpath”, β€œPath”, β€œPaTh”, etc., which would otherwise force simple Tcl code to support a ridiculous number of special cases. the audacity fr fr.

all other environment variables inherited by Tcl are left unmodified. setting an env array variable to blank is the same as unsetting it, because that's just how the underlying Windows OS behaves. and heads up: relying on an existing and empty environment variable will not work on Windows and is discouraged for cross-platform usage 🚫

the following elements of env are special to Tcl:

  • env(HOME) β€” if set, this gives the location of the directory considered to be the current user's home directory, and it's where a call of cd with no arguments, or with just ~ as an argument, will change into. most platforms set this correctly by default; it does not normally need to be set by user code 🏠
  • env(TCL_LIBRARY) β€” if set, it specifies the location of the directory containing library scripts (the value of this variable will be assigned to the tcl_library variable and therefore returned by the command info library). if this variable is not set then a default value is used.
note that this environment variable should not normally be set πŸ™…
  • env(TCLLIBPATH) β€” if set, it must contain a valid Tcl list giving directories to search during auto-load operations. directories must be specified in Tcl format, using / as the path separator, regardless of platform. this variable is only used when initializing the auto_path variable πŸ”
  • env(TCL_TZ), env(TZ) β€” these specify the default timezone used for parsing and formatting times and dates in the clock command. on many platforms, the TZ environment variable is set up by the operating system ⏰
  • env(LC_ALL), env(LC_MESSAGES), env(LANG) β€” these are used by the msgcat package to determine what locale to format messages using 🌍
  • env(TCL_INTERP_DEBUG_FRAME) β€” if it exists, it has the same effect as running interp debug {} -frame 1 as the very first command of each new Tcl interpreter πŸ›

πŸ’œ errorCode πŸ’œ

this variable holds the value of the -errorcode return option set by the most recent error that occurred in this interpreter. it's a list value, and it represents additional information about the error in a form that's easy to process with programs 🧠

the first element of the list identifies a general class of errors, and determines the format of the rest of the list. the following formats for -errorcode return options are used by the Tcl core; individual applications may define additional formats πŸ‘―

  • ARITH code msg β€” this format is used when an arithmetic error occurs (e.g. an attempt to divide zero by zero in the expr command). code identifies the precise error and msg provides a human-readable description of the error. code will be either DIVZERO (for an attempt to divide by zero), DOMAIN (if an argument is outside the domain of a function, such as acos(-3)), IOVERFLOW (for integer overflow), OVERFLOW (for a floating-point overflow), or UNKNOWN (if the cause of the error cannot be determined).

detection of these errors depends in part on the underlying hardware and system libraries, so it's a little bit ymmv 🀷

  • CHILDKILLED pid sigName msg β€” this format is used when a child process has been killed because of a signal. the pid element is the process's identifier (in decimal). the sigName element is the symbolic name of the signal that caused the process to terminate; it will be one of the names from the include file signal.h, such as SIGPIPE. the msg element is a short human-readable message describing the signal, such as β€œwrite on pipe with no readers” for SIGPIPE πŸ’€
  • CHILDSTATUS pid code β€” this format is used when a child process has exited with a non-zero exit status. the pid element is the process's identifier (in decimal) and the code element is the exit code returned by the process (also in decimal) πŸšͺ
  • CHILDSUSP pid sigName msg β€” this format is used when a child process has been suspended because of a signal. the pid element is the process's identifier, in decimal. the sigName element is the symbolic name of the signal that caused the process to suspend; this will be one of the names from the include file signal.h, such as SIGTTIN. the msg element is a short human-readable message describing the signal, such as β€œbackground tty read” for SIGTTIN ⏸️
  • NONE β€” this format is used for errors where no additional information is available for an error besides the message returned with the error. in these cases the -errorcode return option will consist of a list containing a single element whose contents are NONE 🈳
  • POSIX errName msg β€” if the first element is POSIX, then the error occurred during a POSIX kernel call. the errName element contains the symbolic name of the error that occurred, such as ENOENT; this will be one of the values defined in the include file errno.h. the msg element is a human-readable message corresponding to errName, such as β€œno such file or directory” for the ENOENT case 🐧
  • TCL ... β€” indicates some sort of problem generated in relation to Tcl itself, e.g. a failure to look up a channel or variable πŸͺ„

to set the -errorcode return option, applications should use library procedures such as Tcl_SetObjErrorCode, Tcl_SetReturnOptions, and Tcl_PosixError, or they may invoke the -errorcode option of the return command. and here's the fine print: if none of these methods for setting the error code has been used, the Tcl interpreter will reset the variable to NONE after the next error πŸ”


πŸ’… errorInfo πŸ’…

this variable holds the value of the -errorinfo return option set by the most recent error that occurred in this interpreter. this string value will contain one or more lines identifying the Tcl commands and procedures that were being executed when the most recent error occurred β€” its contents take the form of a stack trace, showing the various nested Tcl commands that had been invoked at the time of the error 🧡


more parts coming, don't go anywhere bestie πŸ’–

  • tcl_library β€” bestie, this one holds the name of a directory, and that directory is where the system library of Tcl scripts lives πŸŽ€ β€” you know, all the auto-loading stuff. Want the value? Run info library and it hands it right back to you. The library manual entry has the full tea on what the Tcl script library actually gives you.

So here's the vibe: normally every application or package gets its own application-specific script library on top of the Tcl script library, and each app is supposed to set a global variable named like $app_library (where app is the app's name) to hold the network file name for that app's library directory. Iconic, lowkey.

When an interpreter gets created, the initial value of tcl_library is set by searching a bunch of different directories until one is found that has an appropriate Tcl startup script. If the TCL_LIBRARY environment variable exists, then the directory it names gets checked first πŸ’…. If TCL_LIBRARY isn't set, or it doesn't point at an appropriate directory, then Tcl checks several other directories based on a compiled-in default location, the location of the binary containing the application, and the current working directory. No cap.

  • tcl_patchLevel β€” when an interpreter is created, Tcl sets this variable to hold a string with the current patch level for Tcl ✨ β€” stuff like 8.4.16 for Tcl 8.4 with the first sixteen official patches, or 8.5b3 for the third beta release of Tcl 8.5. The value of this variable is returned by the info patchlevel command. Simple as that.
  • tcl_pkgPath β€” this variable holds a list of directories showing where packages are normally installed πŸ“¦. It is not used on Windows, just so you know. Typically it has either one or two entries; if there are two, the first is normally a directory for platform-dependent packages (e.g., shared library binaries) and the second is normally a directory for platform-independent packages (e.g., script files). Typically a package is installed as a subdirectory of one of the entries in the tcl_pkgPath variable. The directories in tcl_pkgPath are included by default in the auto_path variable, so they and their immediate subdirectories get automatically searched for packages during package require commands.
Note: tcl_pkgPath is not intended to be modified by the application 🚫. Its value is added to auto_path at startup; changes to tcl_pkgPath are not reflected in auto_path. If you want Tcl to search additional directories for packages, you should add the names of those directories to auto_path, not tcl_pkgPath. Periodt.
  • tcl_platform β€” this is an associative array whose elements contain information about the platform the application is running on 🌈 β€” like the name of the operating system, its current release number, and the machine's instruction set. The elements listed below will always be defined, but ngl they may have empty strings as values if Tcl couldn't retrieve any relevant information 😭. Also, extensions and applications may add additional values to the array. The predefined elements are:
    • byteOrder β€” the native byte order of this machine: either littleEndian or bigEndian.
    • debug β€” if this variable exists, then the interpreter was compiled with and linked to a debug-enabled C run-time. This variable will only exist on Windows, so extension writers can specify which package to load depending on the C run-time library that is in use. Heads up: this is not an indication that this core contains symbols.
    • engine β€” the name of the Tcl language implementation. When the interpreter is first created, this is always set to the string Tcl.
    • machine β€” the instruction set executed by this machine, like intel, PPC, 68k, or sun4m. On UNIX machines, this is the value returned by uname -m.
    • os β€” the name of the operating system running on this machine, like Windows NT or SunOS. On UNIX machines, this is the value returned by uname -s.
    • osVersion β€” the version number for the operating system running on this machine. On UNIX machines, this is the value returned by uname -r.
    • pathSeparator β€” the character that should be used to split PATH-like environment variables into their corresponding list of directory names 🧚.
    • platform β€” either windows or unix. This identifies the general operating environment of the machine.
    • pointerSize β€” this gives the size of the native-machine pointer in bytes (strictly, it is same as the result of evaluating sizeof(void*) in C.).
    • threaded β€” if this variable exists, then the interpreter was compiled with threads enabled 🧡.
    • user β€” this identifies the current user based on the login information available on the platform. This value comes from the getuid() and getpwuid() system calls on Unix, and the value from the GetUserName() system call on Windows.
    • wordSize β€” this gives the size of the native-machine word in bytes (strictly, it is same as the result of evaluating sizeof(long) in C.).
  • tcl_precision β€” okay so this variable controls the number of digits to generate when converting floating-point values to strings πŸ”’. It defaults to 0. Applications should not change this value; it's provided for compatibility with legacy code.

The default value of 0 is special β€” it means Tcl should convert numbers using as few digits as possible while still distinguishing any floating point number from its nearest neighbours. The way it differs from using an arbitrarily high value for tcl_precision is that an inexact number like 1.4 will convert as 1.4 rather than 1.3999999999999999, even though the latter is nearer to the exact value of the binary number πŸ’€.

If tcl_precision is not zero, then when Tcl converts a floating point number, it creates a decimal representation of at most tcl_precision significant digits; the result may be shorter if the shorter result represents the original number exactly. If no result of at most tcl_precision digits is an exact representation of the original number, the one that is closest to the original number is chosen. And if the original number lies precisely between two equally accurate decimal representations, then the one with an even value for the least significant digit is chosen; for instance, if tcl_precision is 3, then 0.3125 will convert to 0.312, not 0.313, while 0.6875 will convert to 0.688, not 0.687. Any string of trailing zeroes that remains gets trimmed βœ‚οΈ.

A tcl_precision value of 17 digits is β€œperfect” for IEEE floating-point in that it allows double-precision values to be converted to strings and back to binary with no loss of information. For this reason, you'll often see it as a value in legacy code that must run on Tcl versions before 8.5. It is no longer recommended; as noted above, a zero value is the preferred method πŸ‘‘.

All interpreters in a thread share a single tcl_precision value: changing it in one interpreter will affect all other interpreters as well 😳. Safe interpreters are not allowed to modify the variable.

Valid values for tcl_precision range from 0 to 17.

  • tcl_rcFileName β€” this variable is used during initialization to indicate the name of a user-specific startup file 🌸. If it's set by application-specific initialization, then the Tcl startup code will check whether this file exists and source it if it does. For example, for wish the variable is set to ~/.wishrc for Unix and ~/wishrc.tcl for Windows.
  • tcl_traceCompile β€” the value of this variable can be set to control how much tracing information gets displayed during bytecode compilation πŸ‘€. By default, tcl_traceCompile is zero and no information is displayed. Setting tcl_traceCompile to 1 generates a one-line summary in stdout whenever a procedure or top-level command is compiled. Setting it to 2 generates a detailed listing in stdout of the bytecode instructions emitted during every compilation. This variable is useful in tracking down suspected problems with the Tcl compiler πŸ”.
This variable and functionality only exist if TCL_COMPILE_DEBUG was defined during Tcl's compilation.
  • tcl_traceExec β€” the value of this variable can be set to control how much tracing information gets displayed during bytecode execution ✨. By default, tcl_traceExec is zero and no information is displayed. Setting tcl_traceExec to 1 generates a one-line trace in stdout on each call to a Tcl procedure. Setting it to 2 generates a line of output whenever any Tcl command is invoked that contains the name of the command and its arguments. Setting it to 3 produces a detailed trace showing the result of executing each bytecode instruction. Mentioning that when tcl_traceExec is 2 or 3, commands such as set and incr that have been entirely replaced by a sequence of bytecode instructions are not shown πŸ™ˆ. Setting this variable is useful in tracking down suspected problems with the bytecode compiler and interpreter.
This variable and functionality only exist if TCL_COMPILE_DEBUG was defined during Tcl's compilation.
  • tcl_version β€” when an interpreter is created, Tcl initializes this variable to hold the version number for this version of Tcl in the form x.y 🌟. Changes to x represent major changes with probable incompatibilities, and changes to y represent small enhancements and bug fixes that retain backward compatibility. The value of this variable is returned by the info tclversion command.

πŸ¦‹ OTHER GLOBAL VARIABLES πŸ¦‹

okay so these next ones are the extra girlies, bestie. they're only guaranteed to exist in tclsh and wish executables πŸ’… the Tcl library itself does not define them, but like, a lot of Tcl environments do, so don't be shocked when you see them chilling there ✨

  • argc β€” the number of arguments handed to tclsh or wish. that's it, that's the count πŸŽ€
  • argv β€” a Tcl list of the arguments handed to tclsh or wish. the whole squad, in order 🌸
  • argv0 β€” the script that tclsh or wish started executing (if one was actually specified), otherwise it's just the name that tclsh or wish was invoked by πŸͺž like, "who am i really" energy
  • tcl_interactive β€” holds 1 if tclsh or wish is running interactively (meaning no script was specified and standard input is a terminal-like device) and 0 otherwise πŸ”₯ so it's basically the "are we yapping in the REPL rn" flag

🌈 EXAMPLES 🌈

so say you wanna add a directory to the collection of locations that package require searches β€” like, because your app has some app-specific packages it's using β€” then you gotta update the auto_path variable:

lappend ::auto_path [file join [pwd] "theLibDir"]

periodt πŸ’œ


now here's a simple β€” though ngl, not very robust β€” way to handle command line arguments of the form "-foo 1 -bar 2": just load them into an array, but first load in the default settings ✨ like so:

array set arguments {-foo 0 -bar 0 -grill 0}
array set arguments $::argv
puts "foo is $arguments(-foo)"
puts "bar is $arguments(-bar)"
puts "grill is $arguments(-grill)"

it's giving quick-and-dirty and honestly? valid for a lil script 🫢 but bestie, she said not very robust, she meant it πŸ’€


also!! the argv0 global variable can be used (in conjunction with the info script command, iconic duo πŸ‘‘) to figure out whether the current script is being executed as the main script or loaded as a library. this is genuinely so useful because it lets a single script serve double duty as both a library and a demonstration of that library 😭 obsessed:

if {$::argv0 eq [info script]} {
    # running as: tclsh example.tcl
} else {
    package provide Example 1.0
}

one script, two jobs, main character energy fr fr πŸ’…βœ¨


πŸ‘€ SEE ALSO πŸ‘€

eval(3tcl), library(3tcl), tclsh(1), tkvars(3tcl), wish(1)


πŸ”‘ KEYWORDS πŸ”‘

arithmetic, bytecode, compiler, error, environment, POSIX, precision, subprocess, user, variables


and that's the whole page, bestie!! this was tclvars(3tcl) from Tcl 8.0 β€” go forth and read your global variables with confidence, you absolute scholar πŸŽ€πŸ’–πŸ¦‹ slay, no cap, and remember: the vibe changes but the facts never do πŸŒΈπŸ˜ŒπŸ’œ

πŸ“¦ where this page comes from
  • ubuntu stonking: tcl8.6-doc 8.6.18+dfsg-1
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms