This global variable is provided by tclsh and wish mainline code (and NOT the tcl or tk libraries). It gives you the arguments the app was called with as a list, similar to C's argv, but without the app name itself (you get that in ::argv0). While argc exists, we don't really need it since we can always determine [llength $argv].
An example of making use of this variable is:
#! /usr/local/bin/tclsh
if { $::argc > 0 } {
set i 1
foreach arg $::argv {
puts "argument $i is $arg"
incr i
}
} else {
puts "no command line argument passed"
}
DGP -- It is true that we do not need ::argc, but tclsh and wish and any application embedding Tcl that calls Tcl_Main() provide it anyway.
argv0 describes the name of the top-level script that was invoked via tclsh or wish.
http://purl.org/tcl/home/man/tcl8.3.2/UserCmd/tclsh.htm
http://purl.org/tcl/home/man/tcl8.3.2/UserCmd/wish.htm
Tk's Tk_ArgVInfo function makes a pass over the argv items, and handles some more arguments before placing the remainder in the argv list..
The arguments that these functions look for include:
This means that you should not design your application to require flags of these names or even abbreviations of these! Otherwise, The argvinfo function in Tk grabs them before your application finds them.
See command options for a discussion of various options one has in parsing the argv (and argv-like) information.
Also, note that [info script] describes the name of the currently executing script and this name even gets set by source. Technically, it is set by Tcl_FSEvalFile(), for those using Tcl's C API.
The command [info nameofexecutable] describes the name of the executing binary, and might be thought more like the C level argv[0].
Some code available that helps process the argv arguments include:
Where: ftp://ftp.Lehigh.EDU/pub/evap/evap-2.x/evap-2.2.tar.Z
ftp://ftp.procplace.com/pub/tcl/sorted/packages-7.6/devel/evap-2.1.tar.gz
Description: evaluate_parameters is a Perl program that
processes command line arguments in a simple consistent manner
performing type-checking, multi-levels of help, etc.
generate_tk_program is an auxiliary program which generates
a Tcl/Tk GUI wrapper around one's Perl or C program to gather
the command line arguments interactively.
Updated: 10/1999
Contact: mailto:[email protected] (Stephen O. Lidie) Where: From the contact
Description: Preprocess arguments before calling RecordAndEval or Eval,
surrounding the arguments with braces so they won't be sub-evaluated.
Updated:
Contact: mailto:[email protected] (Matt DiMeo) Where: http://www.csua.berkeley.edu/%7Esls/woa/distrib/
ftp://ftp.procplace.com/pub/tcl/sorted/packages-7.6/devel/sntl-0.4.2.tar.gz
ftp://ftp.procplace.com/pub/tcl/sorted/packages-7.6/devel/sntl-0.4.2p1.patch.tar.gz
Description: A general Tcl library of procedures. Contains code to
produce man pages from Tcl source, conversions from Tcl to C,
HTML rendering, generating HTML, handling CGI forms, command line
argument processing, a debugging message system, an object system,
and various Tk widgets built with the object system.
Updated: 10/1998
Contact: mailto:[email protected] (Sam Shen)
mailto:[email protected] (Sam Shen)Schelte Bron wrote in the comp.lang.tcl newsgroup on 2004-02-19: I sometimes use numbers as variable names for a list of arguments like argv in the main script or args inside a proc.
set i 0; foreach n $argv {set [incr i] $n}I can then refer to the arguments as $1, $2, etc. just like in sh/ksh/bash.
rdt Uhh, can't you just have the proc use those name? i.e.
proc xyz {1 2 3} {
# use the args as:
puts "1=$1, 2=$2, 3=$3"
}What's wrong with that if that is what you want?
sbron There's nothing wrong with that, in a different situation. The point was having easy access to an unknown number of arguments.
rdt I see. Yes that is additional capability, thanks.
MG adds that (especially when you're doing it outside a proc, and so the variables are all persistant) you should add an 'unset i n' to the end of the code above, just to clean up properly.