SEMINAR REPORT

ON
TOOL COMMAND LANGUAGE

TABLE OF COTENTS :

 Introduction to Tcl
• Scripting : Higher Level Programming For 21st
Century
 The Birth of Tcl
 An Introduction to Tcl Syntax
• Setting up Environment Variables
 Tcl Built in Commands
 The Tcl War
 Introduction to Tcl
TCL/TKs (Tool Command Language/Tool Kit) strength is that it is a small, interpreted,
language that can be embedded, access graphics and system features, and is extensible. It
also is multiplatform and has very wide support. It can be downloaded on the NET, and it
runs TCL scripts for backend processing. TCL is a language, called the Tool Command
Language. TK is a set of extensions or "widgets"(the actual official designation) that
happened to be written by TCL’s author to add graphic capability to his TCL interpreter
they include things like list boxes, entry boxes, radio buttons, check boxes, etc.... In fact,
prior to TCL/TK 8.0, TCL was at version 7.3, and TK was at version 4, as I recall. In a
way, TCL’s relationship to TK is kind of like VBs relationship to activex(which ALSO
has controls as mentioned above, and are sold as one package). In fact, a VB user can
program for a long time without realizing that he or she is using activex components all
over the place.

Tcl was originally intended to be a reusable command language. Its developers had been
creating a number of interactive tools, each requiring its own command language. Since
they were more interested in the tools themselves than the command languages they
would employ, these command languages were constructed quickly, without regard to
proper design.

After implementing several such "quick-and-dirty" command languages and experiencing

problems with each one, they decided to concentrate on implementing a general-purpose,
robust command language that could easily be integrated into new applications. Thus Tcl
(Tool Command Language) was born.

Since that time, Tcl has been widely used as a scripting language. In most cases, Tcl is
used in combination with the Tk ("Tool Kit") library, a set of commands and procedures
that make it relatively easy to program graphical user interfaces in Tcl.

One of Tcl's most useful features is its extensibility. If an application requires some
functionality not offered by standard Tcl, new Tcl commands can be implemented using
the C language, and integrated fairly easily. Since Tcl is so easy to extend, many people
have written extension packages for some common tasks, and made these freely available
on the internet.
 Scripting: Higher Level Programming For 21st Century

Scripting languages such as Perl and Tcl represent a very different style of programming
than system programming languages such as C or JavaTM. Scripting languages are
designed for "gluing" applications; they use typeless approaches to achieve a higher level
of programming and more rapid application development than system programming
languages. Increases in computer speed and changes in the application mix are making
scripting languages more and more important for applications of the future.
Introduction

For the last fifteen years a fundamental change has been occurring in the way people
write computer programs. The change is a transition from system programming
languages such as C or C++ to scripting languages such as Perl or Tcl. Although many
people are participating in the change, few people realize that it is occurring and fewer
people know why it is happening. Scripting languages will handle many of the
programming tasks of the next century better than system programming language.
Scripting languages are designed for different tasks than system
programming languages, and this leads to fundamental differences in the languages.
System programming languages were designed for building data structures and
algorithms from scratch, starting from the most primitive computer elements such as
words of memory. In contrast, scripting languages are designed for gluing: they assume
the existence of a set of powerful components and are intended primarily for connecting
components together. System programming languages are strongly typed to help manage
complexity, while scripting languages are typeless to simplify connections between
components and provide rapid application development uages.
Scripting languages and system programming languages are
complementary, and most major computing platforms since the 1960's have provided
both kinds of languages. The languages are typically used together in component
frameworks, where components are created with system programming languages and
glued together with scripting languages. However, several recent trends, such as faster
machines, better scripting languages, the increasing importance of graphical user
interfaces and component architectures, and the growth of the Internet, have greatly
increased the applicability of scripting languages. These trends will continue over the
next decade, with more and more new applications written entirely in scripting languages
and system programming languages used primarily for creating components.

System programming languages

In order to understand the differences between scripting languages and system

programming languages, it is important to understand how system programming
languages evolved. System programming languages were introduced as an alternative to
assembly languages. In assembly languages, virtually every aspect of the machine is
reflected in the program. Each statement represents a single machine instruction and
programmers must deal with low-level details such as register allocation and procedure
calling sequences. As a result, it is difficult to write and maintain large programs in
assembly language.

By the late 1950's higher level languages such as Lisp, Fortran, and Algol began to
appear. In these languages statements no longer correspond exactly to machine
instructions; a compiler translates each statement in the source program into a sequence
of binary instructions. Over time a series of system programming languages evolved from
Algol, including such languages as PL/1, Pascal, C, C++, and Java. System programming
languages are less efficient then assembly languages but they allow applications to be
developed much more quickly. As a result, they have almost completely replaced
assembly languages for the development of large applications.

System programming languages differ from assembly languages in two ways: they are
higher level and they are strongly typed. The term "higher level" means that many details
are handled automatically so that programmers can write less code to get the same job
done. For example:

• Register allocation is handled by the compiler so that programmers need not write
code to move information between registers and memory.
• Procedure calling sequences are generated automatically: programmers need not
worry about moving arguments to and from the call stack.
• Programmers can use simple keywords such as while and if for control
structures; the compiler generates all the detailed instructions to implement the
control structures.

On average, each line of code in a system programming language translates to about five
machine instructions, compared to one instruction per line in assembly language (in an
informal analysis of eight C files written by five different people, It was found that the
ratio ranged from about 3 to 7 instructions per line in a study of numerous languages
Capers Jones found that for a given task, assembly languages require about 3-6 times as
many lines of code as system programming languages). Programmers can write roughly
the same number of lines of code per year regardless of language, so system
programming languages allow applications to be written much more quickly than
assembly language.

The second difference between assembly language and system programming

languages is typing. I use the term "typing" to refer to the degree to which the meaning of
information is specified in advance of its use. In a strongly typed language the
programmer declares how each piece of information will be used and the language
prevents the information from being used in any other way. In a weakly typed language
there are no a priori restrictions on how information can be used: the meaning of
information is determined solely by the way it is used, not by any initial promises.1

Modern computers are fundamentally typeless: any word in memory can hold any kind of
value, such as an integer, a floating-point number, a pointer, or an instruction. The
meaning of a value is determined by how it is used: if the program counter points at a
word of memory then it is treated as an instruction; if a word is referenced by an integer
add instruction then it is treated as an integer; and so on. The same word can be used in
different ways at different times.

Different tools for different tasks

A scripting language is not a replacement for a system programming language or vice
versa. Each is suited to a different set of tasks. For gluing and system integration,
applications can be developed 5-10x faster with a scripting language; system
programming languages will require large amounts of boilerplate and conversion code to
connect the pieces, whereas this can be done directly with a scripting language. For
complex algorithms and data structures, the strong typing of a system programming
language makes programs easier to manage. Where execution speed is key, a system
programming language can often run 10-20x faster than a scripting language because it
makes fewer run-time checks.

In deciding whether to use a scripting language or a system programming language for a

particular task, consider the following questions:

• Is the application's main task to connect together pre-existing components?

• Will the application manipulate a variety of different kinds of things?
• Does the application include a graphical user interface?
• Does the application do a lot of string manipulation?
• Will the application's functions evolve rapidly over time?
• Does the application need to be extensible?
"Yes" answers to these questions suggest that a scripting language will work well for the
application. On the other hand, "yes" answers to the following questions suggest that an
application is better suited to a system programming language:

• Does the application implement complex algorithms or data structures?

• Does the application manipulate large datasets (e.g. all the pixels in an image) so
that execution speed is critical?
• Are the application's functions well-defined and changing slowly?

Scripting and system programming are symbiotic. Used together, they produce
programming environments of exceptional power: system programming languages are
used to create exciting components which can then be assembled using scripting
languages. For example, much of the attraction of Visual Basic is that system
programmers can write ActiveX components in C and less sophisticated programmers
can then use the components in Visual Basic applications. In Unix it is easy to write shell
scripts that invoke applications written in C. One of the reasons for the popularity of Tcl
is the ability to extend the language by writing C code that implements new commands.

Scripting is on the rise

Scripting languages have existed for a long time, but in recent years several factors have
combined to increase their importance. The most important factor is a shift in the
application mix towards gluing applications. Three examples of this shift are graphical
user interfaces, the Internet, and component frameworks.

The growth of the Internet has also popularized scripting

languages. The Internet is nothing more than a gluing tool. It doesn't create any new
computations or data; it simply makes a huge number of existing things easily accessible.
The ideal language for most Internet programming tasks is one that makes it possible for
all the connected components to work together, i.e. a scripting language. For example,
Perl has become popular for writing CGI scripts and JavaScript is popular for scripting in
Web pages. Another reason for the increasing popularity of scripting languages is
improvements in scripting technology. Scripting technology is still relatively immature
even today. For example, Visual Basic isn't really a scripting language; it was originally
implemented as a simple system programming language, then modified to make it more
suitable for scripting. Future scripting languages will be even better than those available
today. Scripting technology is still relatively immature even today. For example, Visual
Basic isn't really a scripting language; it was originally implemented as a simple system
programming language, then modified to make it more suitable for scripting. Future
scripting languages will be even better than those available today.

Today the number of applications written in scripting languages is much greater than the
number of applications written in system programming languages. Scripting languages
are already a major force in application development and their market share will increase
in the future.
Scripting languages have actually generated significant software reuse. They use a model
where interesting components are built in a system programming language and then glued
together into applications using the scripting language. This division of labor provides a
natural framework for reusability. Components are designed to be reusable, and there are
well-defined interfaces between components and scripts that make it easy to use
components. For example, in Tcl the components are custom commands implemented in
C; they look just like the builtin commands so they are easy to invoke in Tcl scripts. In
Visual Basic the components are ActiveX extensions, which can be used by dragging
them from a palette onto a form. Scripting languages represent a different set of tradeoffs
than system programming languages. They give up execution speed and strength of
typing relative to system programming languages but provide significantly higher
programmer productivity and software reuse. This tradeoff makes more and more sense
as computers become faster and cheaper in comparison to programmers. System
programming languages are well suited to building components where the complexity is
in the data structures and algorithms, while scripting languages are well suited for gluing
applications where the complexity is in the connections. Gluing tasks are becoming more
and more prevalent, so scripting will become an even more important programming
paradigm in the next century than it is today.
Scripting languages represent a different set of tradeoffs than system programming
languages. They give up execution speed and strength of typing relative to system
programming languages but provide significantly higher programmer productivity and
software reuse. This tradeoff makes more and more sense as computers become faster
and cheaper in comparison to programmers. System programming languages are well
suited to building components where the complexity is in the data structures and
algorithms, while scripting languages are well suited for gluing applications where the
complexity is in the connections. Gluing tasks are becoming more and more prevalent, so
scripting will become an even more important programming paradigm in the next century
than it is today.
 The birth of Tcl
The Tcl scripting language grew out on design tools for integrated circuits at the
University of California at Berkeley in the early 1980's.

The notion of embeddability is one of the most unique aspects of Tcl, and it led to the
following three overall goals for the language:

• The language must be extensible: it must be very easy for each application to add
its own features to the basic features of the language, and the application-specific
features should appear natural, as if they had been designed into the language
from the start.
• The language must be very simple and generic, so that it can work easily with
many different applications and so that it doesn't restrict the features that
applications can provide.
• Since most of the interesting functionality will come from the application, the
primary purpose of the language is to integrate or "glue together" the extensions.
Thus the language must have good facilities for integration.

The conclusion that to reduce the resource requirements by building large systems out of
reusable components. If most of the complexity of a system was in the components, and
it could carry the components forward from system to system, perhaps it could build
large powerful systems .

The additional resources provided by Sun make major improvements to Tcl

and Tk. Scott Stanton and Ray Johnson ported Tcl and Tk to Windows and the
Macintosh, so that Tcl became an outstanding cross-platform development environment;
today, more than two-thirds of Tcl downloads are for Windows.
An Introduction to Tcl Syntax

For a scripting language, Tcl has a simple syntax.

cmd arg arg arg
A Tcl command is formed by words separated by white space. The first word is
the name of the command, and the remaining words are arguments to the
command.
$foo
The dollar sign ($) substitutes the value of a variable. In this example, the variable
name is foo.
[clock seconds]
Square brackets execute a nested command. For example, if you want to pass the
result of one command as the argument to another, you use this syntax. In this
example, the nested command is clock seconds, which gives the current time in
seconds.
"some stuff"
Double quotation marks group words as a single argument to a command. Dollar
signs and square brackets are interpreted inside double quotation marks.
{some stuff}
Curly braces also group words into a single argument. In this case, however,
elements within the braces are not interpreted.
\
The backslash (\) is used to quote special characters. For example, \n generates a
newline. The backslash also is used to "turn off" the special meanings of the
dollar sign, quotation marks, square brackets, and curly braces.
A Little Example

Below is a Tcl command that prints the current time. It uses three Tcl commands: set,
clock, and puts. The set command assigns the variable. The clock command
manipulates time values. The puts command prints the values.

set seconds [clock seconds]

puts "The time is [clock format $seconds]"

Note that you do not use $ when assigning to a variable. Only when you want the value
do you use $. The seconds variable isn't needed in the previous example. You could print
the current time with one command:

puts "The time is [clock format [clock seconds]]"

Grouping and Substitution

The Tcl syntax is used to guide the Tcl parser through three steps: argument grouping,
result substitution, and command dispatch.

1. Argument grouping. Tcl needs to determine how to organize the arguments to

the commands. In the simplest case, white space separates arguments. As stated
earlier, the quotation marks and braces syntax is used to group multiple words
into one argument. In the previous example, double quotation marks are used to
group a single argument to the puts command.
2. Result substitution. After the arguments are grouped, Tcl performs string
substitutions. Put simply, it replaces $foo with the value of the variable foo, and
it replaces bracketed commands with their result. That substitutions are done after
grouping is crucial. This sequence ensures that unusual values do not complicate
the structure of commands.
3. Command dispatch. After substitution, Tcl uses the command name as a key into
a dispatch table. It calls the C procedure identified in the table, and the C
procedure implements the command. You also can write command procedures in
Tcl. There are simple conventions about argument passing and handling errors.

Another Example

Here is another example:

set i 0
while {$i < 10} {
puts "$i squared = [expr {$i*$i}]"
incr i
}
Here, curly braces are used to group arguments without doing any substitutions. The Tcl
parser knows nothing special about the while command. It treats it like any other
command. It is the implementation of the while command knows that the first argument
is an expression, and the second argument is more Tcl commands. The braces group two
arguments: the boolean expression that controls the loop and the commands in the loop
body.

We also see two math expressions: the boolean comparison and multiplication. The while
command automatically evaluates its first argument as an expression. In other cases you
must explicitly use the expr command to perform math evaluation.

Command Dispatch

Lastly, Tcl calls something else to do the hard work. We've seen that Tcl uses expr to
perform math functions, puts to handle output functions, and set to assign variables.
These Tcl commands are implemented by a C procedure that has registered itself with
Tcl. The C command procedures take the string arguments from the Tcl command and
return a new string as their result. It is very easy to write C command procedures. They
can do everything from accessing databases to creating graphical user interfaces. Tcl, the
language, doesn't really know what the commands do. It just groups arguments,
substitutes results, and dispatches commands.

One other Example

Here is the factorial procedure:

proc fac {x} {

if {$x < 0} {
error "Invalid argument $x: must be a positive integer"
} elseif {$x <= 1} {
return 1
} else {
return [expr {$x * [fac [expr {$x-1}]]}]
}
}

Setting up Environment Variables

The binaries and libraries of Tcl/Tk and its extensions such as blt etc are generally
installed under /usr/bin and /usr/lib. If this is not the case (i.e. they are compiled
but not installed under /usr) , we need to set up a few environment variables .

e.g., If the master directory is ~/tcl then

setenv TCL_LIBRARY ~/tcl/itcl/lib/tcl7.4

setenv TK_LIBRARY ~/tcl/itcl/lib/tk4.0
 setenv ITCL_LIBRARY ~/tcl/itcl/lib/itcl2.0
setenv ITK_LIBRARY ~/tcl/itcl/lib/itk2.0
setenv IWIDGETS_LIBRARY ~/tcl/itcl/lib/iwidgets2.0
setenv EXPECT_LIBRARY ~/tcl/expect/lib
setenv BLT_LIBRARY ~/tcl/blt/lib

Our search path should be set up to pick up the correct binaries for tclsh, wish
or itkwish etc. Make sure you include the pathnames in your set path in our
.login or .cshrc or .profile file

tclsh
The starting point to writing your own Tcl scripts is to familiarise ourself with Tcl
syntax and learn the core Tcl commands. Take the first step by typing tclsh at
command level in your commandtool/shelltool/xterm. Shell will invoke tclsh to
prompt sign will change to % to indicate tclsh is ready to read your Tcl
commands from the keyboard and pass them to the Tcl interpreter for evaluation.

Every Tcl command consists of one or more words, the first of which is the name
of the C function to be invoked by the interpreter. The rest of the words in the
command are passed as arguments for the C procedure. The C function provided
by the Tcl library. Tcl library contains functions to provide a full set of
programming features to Tcl such as variables, control flow etc. Use the Basics of
Tcl application to explore these. we can write your own functions as well and
register them with Tcl interpreter. The following simple commands to test and get
a flavour of Tcl:

expr 10 * 5
tclsh will print 50 and prompt you again.
expr is a core Tcl application for carrying out arithmetic operations. expr returns 1
for true and 0 for false for Boolean values when it evaluates relational operations..
Try:
% puts "Hi there"

You will get:

Hi There
%

Each Tcl command is separated either by a newline or a semicolon. Backslash in a

command tells Tcl that the command continues in the next line.

Try
% puts "Hi there going to \
next line "
 You will get:

Hi there going to next line

%

Type

% exit

to quit tclsh.
wish
Most applications would want to use Tcl as the basis for scripting and assembling
their modules together but create their own commands based on one or more
extensions of Tcl, in particular Tk, the toolkit of commands for building window-
based Tcl applications. Without Tk, Tcl remains yet another scripting language.

Tk (and all Tcl) commands can be invoked within the tk windowing shell wish.

Try (at command level of commandtool/shelltool/xterm):

wish

The result will look like:

 The wish mainwindow is placed within the xterm that invoked it.
Tcl and Tk on World Wide Web

Compressed tar file of Tcl/Tk manual pages in Hypertext Markup Language are available
from ftp://ftp.funet.fi/pub/languages/tcl/contrib/docs. The Tcl/Tk Reference Guide (latex
document) can also be fetched from the same source.

Tcl Built-In Commands

NAME
for - ``For'' loop

for start test next body

DESCRIPTION
For is a looping command, similar in structure to the C for statement. The start,
next, and body arguments must be Tcl command strings, and test is an expression string.
The for command first invokes the Tcl interpreter to exe-cute start. Then it repeatedly
evaluates test as an expression; if the result is non-zero it invokes the Tcl
interpreter on body, then invokes the Tcl interpreter on next, then repeats the loop. The
command terminates when test evaluates to 0. If a continue command is invoked
within body then any remaining commands in the current execution of body are
skipped; processing continues by invoking the Tcl interpreter on next, then evaluating
 test, and so on. If a break command is invoked within body or next, then the for
command will return immediately. The operation of break and continue are similar to
the corresponding statements in C. For returns an empty string.

NAME
case - Evaluate one of several scripts, depending on a
given value

case string ?in? patList body ?patList body ...?

case string ?in? {patList body ?patList body ...?}

DESCRIPTION
The case command is obsolete and is supported only for backward compatibility.
At some point in the future it may be removed entirely. You should use the switch
command instead.

The case command matches string against each of the patList arguments in
order. Each patList argument is a list of one or more patterns. If any of these patterns
matches string then case evaluates the following body argument by passing it
recursively to the Tcl interpreter and returns the result of that evaluation. Each patList
argument consists of a single pattern or list of patterns.
Each pattern may contain any of the wild-cards described under string match. If a
patList argument is default, the corresponding body will be evaluated if no patList
matches string. If no patList argument matches string and no default is given, then the
case command returns an empty string.

Two syntaxes are provided for the patList and body arguments. The first uses a
separate argument for each of the patterns and commands; this form is convenient if
substitutions are desired on some of the patterns or commands.
The second form places all of the patterns and commands together into a single
argument; the argument must have proper list structure, with the elements of the list
being the patterns and commands. The second form makes it easy to construct multi-
line case commands, since the braces around the whole list make it unnecessary to
include a backslash at the end of each line. Since the patList arguments are in braces
in the second form, no command or variable substitutions are performed on them; this
makes the behavior of the second form different than the first form in some cases.

NAME
append - Append to variable

append varName ?value value value ...?

DESCRIPTION
Append all of the value arguments to the current value of variable varName. If
varName doesn't exist, it is given a value equal to the concatenation of all the value
arguments. This command provides an efficient way to build up long variables
incrementally. For example, ``append a$b'' is much more efficient than ``set a $a$b'' if
$a is long.

NAME
catch - Evaluate script and trap exceptional returns

catch script ?varName?

DESCRIPTION
The catch command may be used to prevent errors from aborting command
interpretation. Catch calls the Tcl interpreter recursively to execute script, and
always returns a TCL_OK code, regardless of any errors that might occur while
executing script. The return value from catch is a decimal string giving the code
returned by the Tcl interpreter after executing script. This will be 0 (TCL_OK) if
there were no errors in script; otherwise it will have a non-zero value corresponding
to one of the exceptional return codes (see tcl.h for the definitions of code values). If
the varName argument is given, then it gives the name of a variable; catch will set the
variable to the string returned from script (either a result or an error message).

catch catches all exceptions, including those generated by break and continue as
well as errors.

NAME
array - Manipulate array variables

array option arrayName ?arg arg ...?

DESCRIPTION
This command performs one of several operations on the variable given by
arrayName. Unless otherwise specified for individual commands below, arrayName
must be the name of an existing array variable. The option argument determines what
action is carried out by the command. The legal options (which may be abbreviated)
are:

array anymore arrayName searchId

Returns 1 if there are any more elements left to be processed in an array search, 0
if all elements have already been returned. SearchId indicates which search on
arrayName to check, and must have been the return value from a previous invocation of
array startsearch. This option is particularly useful if an array has an element
with an empty name, since the return value from array nextelement won't indicate
whether the search has been completed.
 array donesearch arrayName searchId
This command terminates an array search and destroys all the state
associated with that search. SearchId indicates which search on arrayName to
destroy, and must have been the return value from a previous invocation of array
startsearch. Returns an empty string.

array exists arrayName

Returns 1 if arrayName is an array variable, 0 if there is no variable by that
name or if it is a scalar variable.

array get arrayName ?pattern?

Returns a list containing pairs of elements. The first element in each pair is
the name of an element in arrayName and the second element of each pair is the value
of the array element. The order of the pairs is undefined. If pattern is not spec
ified, then all of the elements of the array are included in the result. If pattern is
specified, then only those elements whose names match pattern (using the glob-style
matching rules of string match) are included. If arrayName isn't the name of an array
variable, or if the array contains no elements, then an empty list is returned.
array names arrayName ?pattern?
Returns a list containing the names of all of the elements in the array that match
pattern (using the globstyle matching rules of string match). If pattern is omitted
then the command returns all of the element names in the array. If there are no
(matching) elements in the array, or if arrayName isn't the name of an array variable,
then an empty string is returned.

array nextelement arrayName searchId

Returns the name of the next element in arrayName, or an empty string if all
elements of arrayName have already been returned in this search. The searchId
argument identifies the search, and must have been the return value of an array
startsearch
command. Warning: if elements are added to or deleted from the array, then
all searches are automatically terminated just as if array donesearch had been invoked;
this will cause array nextelement operations to fail for those searches.

array set arrayName list

Sets the values of one or more elements in array Name. list must have a form
like that returned by array get, consisting of an even number of elements. Each odd-
numbered element in list is treated as an element name within arrayName, and
the following element in list is used as a new value for that array element.

array size arrayName

Returns a decimal string giving the number of elements in the array. If
arrayName isn't the name of an array then 0 is returned.

array startsearch arrayName

 This command initializes an element-by-element search through the array
given by arrayName, such that invocations of the array nextelement command
will return the names of the individual elements in the array. When the search has been
completed, the array donesearch command should be invoked. The return value is a
search identifier that must be used in array nextelement and array donesearch com-
mands; it allows multiple searches to be underway simultaneously for the same array.

NAME
puts - Write to a file

puts ?-nonewline? ?fileId? string

DESCRIPTION
Writes the characters given by string to the file given by fileId. FileId must have
been the return value from a previous call to open, or it may be stdout or stderr to
refer to one of the standard I/O channels; it must refer to a file that was opened for
writing. If no fileId is specified then it defaults to stdout. Puts normally outputs a
newline character after string, but this feature may be suppressed by specifying the
-nonewline switch.
Output to files is buffered internally by Tcl; the flush command may be used to
force buffered characters to be output.

NAME
gets - Read a line from a file gets fileId ?varName?
DESCRIPTION
This command reads the next line from the file given by fileId and discards the
terminating newline character. If varName is specified then the line is placed in the
variable by that name and the return value is a count of the number of characters read
(not including the newline). If the end of the file is reached before reading any charac-
ters then -1 is returned and varName is set to an empty string. If varName is not
specified then the return value will be the line (minus the newline character) or an empty
string if the end of the file is reached before reading any characters. An empty string
will also be returned if a line contains no characters except the newline, so eof may have
to be used to determine what really happened. If the last character in the file is not a
newline character then gets behaves as if there were an additional newline character at
the end of the file. FileId must be stdin or the return value from a previous call to
open; it must refer to a file that was opened for reading. Any existing end-of-file or
error condition on the file is cleared atthe beginning of the gets command.

The Tcl War

Tcl was not designed to be a serious programming language. It was designed to be a
"scripting language", on the assumption that a "scripting language" need not try to be a
real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes having numbers, which
works, but has to be slow. Tcl is ok for writing small programs, but when you push it
beyond that, it becomes insufficient.

Tcl is very slow. Tcl stores arrays as strings, making vector-ref take time linear in the number of
elements. Tcl's associative arrays ("array variables") are implemented as hash tables, but the only
key type is strings, making this facility very slow as well.
> Tcl has a peculiar syntax that appeals to hackers because of it simplicity.
But Tcl syntax seems strange to most users.
> If Tcl does become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.

But Tcl has (simulated) lexically scoped local variables,

while many scripting languages (eg, elisp or perl4) have only
dynamically scoped variables. Tcl allows new control-flow
structures to be coined, which is an important structuring
primitive
The Nine Rules of Tcl Nobody Seems to Bother to Read that’s why it feel problematic

1) a script is broken into commands at newline and semicolon

2) command evaluation proceeds by simple dispatch on the first
word of a command after substitutions described in 3-9
3) a command is broken into words at whitespace
4-8) if the first character of a word is " or {,
do " or { quotation to form the word,
if a word contains [, $ or \,
do command, variable, or backslash substution into the word
9) if a # is encountered as the first character of the first word
of a command, the characters up to and including the
following newline are ignored as a comment

True, some of the subtleties aren't captured here, especially that

rules 4-8 can gobble up whitespace, and some \ behavior. But the
above 9 rules[2], subtelties and all, with rules 3-9 being applied
on a single level scan, are all there is to lexing and parsing Tcl,
and they are all right on the Tcl(n) man page.
Even though it can probably be interpreted, it looks to me as a compiled
language. As such, I think it makes people working on medium to
large projects happy because the compiler helps everything stay
efficient, consistant, and maintainable. Tcl does hardly anything
in this area. However, Tcl makes it possible to do small things
quickly, and to write programs that can be customized by endusers with very little effort.

Tcl: award-winning software

In the spring of 1998 there was a wonderful news that Tcl had won two major awards.
The first is the ACM Software System Award, awarded each year for "a software system
that has had a lasting influence". Past winners of the award include such seminal systems
as the TCP/IP protocols, the first spreadsheets, the first relational databases, the World-
Wide Web, Unix, PostScript, and Smalltalk. The second award was the USENIX
Software Tools User Group (STUG) Award, given each year in recognition of an
outstanding software tool.
 BIBLIOGRAPHY

• http//www.computerhope.com
• http//www.opengroup.com
• http//www.citeseer.nj.nec.com
• http//www.bitd.clrc.ac.uk
• http//www.tcl.vandeburg.org