Introduction

TCL tricks

tclsh vs wish

tclsh is a shell-like application that reads Tcl commands from its standard input or from a file and evaluates them. If invoked with no arguments then it runs interactively, reading Tcl commands from standard input and printing command results and error messages to standard output. It runs until the exit command is invoked or until it reaches end-of-file on its standard input. If there exists a file .tclshrc (or tclshrc.tcl on the Windows platforms) in the home directory of the user, tclsh evaluates the file as a Tcl script just before reading the first command from standard input.

Wish on the other hand is a simple program consisting of the Tcl command language, the Tk toolkit, and a main program that reads commands from standard input or from a file. It creates a main window and then processes Tcl commands. If wish is invoked with arguments, then the first few arguments, ?-encoding name? ?fileName? specify the name of a script file, and, optionally, the encoding of the text data stored in that script file. A value for fileName is recognized if the appropriate argument does not start with “-”.

If there are no arguments, or the arguments do not specify a fileName, then wish reads Tcl commands interactively from standard input. It will continue processing commands until all windows have been deleted or until end-of-file is reached on standard input. If there exists a file “.wishrc” in the home directory of the user, wish evaluates the file as a Tcl script just before reading the first command from standard input.

If arguments to wish do specify a fileName, then fileName is treated as the name of a script file. Wish will evaluate the script in fileName (which presumably creates a user interface), then it will respond to events until all windows have been deleted. Commands will not be read from standard input. There is no automatic evaluation of “.wishrc” when the name of a script file is presented on the wish command line, but the script file can always source it if desired.

Note that on Windows, the wishversion.exe program varies from the tclshversion.exe program in an additional important way: it does not connect to a standard Windows console and is instead a windowed program. Because of this, it additionally provides access to its own console command.

Tcl under Linux

When starting tclsh under Linux, you can't use history ( arrow-up key ). But because history is very handy you can use the rlfe-tool to regain history. 

rlfe lets you use history and line-editing in any text oriented tool. This is especially useful with third-party proprietary tools that cannot be distributed linked against readline. It is not perfect but it works pretty well.
(source: manpage rlfe)

Ubuntu/debian installation and use:

debie@laptopdebie:~/ sudo apt-get install rlfe debie@laptopdebie:~/ rlfe tclsh

Show loaded libs

When you want to know if ByteBlower API is loaded you can use the following command:

% info loaded

This will return a list describing all of the packages that have been loaded into the interpreter. When the ByteBlower API was loaded you should find in the list an entry looking like this

{/usr/local/share/tcltk/ByteBlowerLL/linux/x86_64/default/libbbapi.so Bbapi} {/usr/local/share/tcltk/ByteBlowerLL/linux/x86_64/libtbcload-1.7.so Tbcload}

Show tcl version

To know the version of your TCL, just execute following simple command in the tclshell. The returnvalue will be the version

% info tclversion
8.5

ByteBlower API Tricks

--help

Getting help on a method. Assume you have a ByteBlower Object, lets say ByteBlowerServer Object. If you want to know the syntax of a particular method or the description of what this method does, you can ask with --help. Example:

% set server [ ByteBlower Server.Add byteblower-dev-1-1.lab.byteblower.excentis.com
ByteBlowerObject_1385568352_2
% $server Port.Create --help
ByteBlowerServer {
Parameters:
interface: Interface on which the ByteBlower port must be created.

Description: 
Creates a ByteBlower port on the ByteBlower server on the given interface.

Returns: 
The new ByteBlower port.
}
%

Now we know that PortCreate creates a ByteBlower Port on the ByteBlower server and that we need to give 1 parameter: the interface. So the command will look like this

% set server [ ByteBlower Server.Add byteblower-dev-1-1.lab.byteblower.excentis.com
ByteBlowerObject_1385568352_2
% $server Port.Create trunk-1-1
ByteBlowerObject_1385568352_3
%

Description.Get

An other helpfull method of any ByteBlowerObject is the Description.Get method. This will return a full description of the object.

% $port Description.Get
ByteBlowerPort: {
 Name: trunk-1-1
 EthernetConfiguration: {
 Encoding: DIX
 MAC: 00:FF:1C:00:00:01
 }
 IPv4Configuration: {
 Gateway: 10.1.1.1
 IP: 10.1.1.5
 Netmask: 255.255.255.0
 }
}

Introspector

The introspector is a unique way to visualize the ByteBlower objects. Every ByteBlower-object has next to the method Description.Get a method Tk. Executing this method on a ByteBlower Object will reveal the Introspector.

The introspector consists out of 2 main parts. Left you find the class method tree. This tree contains all the public available methods in alphabetical order. On the right is the result window. Here you will find the result of the evocation of a method in the introspector on this object. On the bottom you will find the inputfield you can use to execute a method on this object.

( Blogpost Charlie !!! )