Is errorInfo the only way you debug TCL
parag...@hotmail.com
can yo help me out
Also,
I am not for, adding more posts . Also wanted to know,
Does TCL complete half commands, depending on the list of keywords
This thing worked for me in TCL
set infile [ope "myfile.txt" r]
And it gave me file3 as the id
Bryan Oakley
Answer to question in the subject: no. Or yes. It depends on what you
really mean. Certainly, errorInfo is the place to look for stack
information when an error occurs (well, that and the info command).
There are many ways to debug code besides peeking at that variable, however.
If you can give a less broad question we can do a better job of giving a
less broad answer.
> Also,
> I am not for, adding more posts . Also wanted to know,
>
> Does TCL complete half commands, depending on the list of keywords
> This thing worked for me in TCL
> set infile [ope "myfile.txt" r]
>
When run interactively from a console, yes. When run from a script, no.
--
Bryan Oakley
http://www.tclscripting.com
parag...@hotmail.com
that I am working. I would have given the user some procedures that
would be in script.
Thansk Bryan
Had I gone ahead with it, I would later had to rethink the project.
Bryan Oakley
> Why is this difference.
Because it makes it easier to experiment in an interactive session.
> Since it is very important for a new project
> that I am working. I would have given the user some procedures that
> would be in script.
I don't understand what you just said, but it sounds like you
misunderstand what I wrote.
It doesn't matter where the procedures are defined. It matters whether a
procedure is typed in by a person from a console or whether it is run
from a script.
If you write procedures, put them in a file, give the file to someone,
and they load them up into an interactive tcl shell, they can use
abbreviated forms of the procedure names. It's just that within the
procs, they must use fully spelled out commands.
There's nothing special about procs in a script, what is special is
rather someone uses those commands in an interactive shell or not.
Does that make sense?
Neil Madden
The behaviour is controlled by the "tcl_interactive" variable and the
procedure "unknown", which is called whenever a command cannot be found.
When using tclsh interactively (i.e., when typing in commands at the %
prompt), tcl_interactive will be set to 1, and "unknown" will search for
any commands which have that command name as a prefix. When you run the
same code from a script however (i.e. by running something like "tclsh
myscript.tcl") then tcl_interactive will be set to 0 and "unknown" will
not perform this behaviour.
Note that this is really just a convenience when using tclsh as a
command shell. You should always write the full command name when
writing a script, for several reasons: (i) it makes the code clearer to
read, (ii) it avoids an expensive call to the unknown procedure when
looking up the command, (iii) it is safer. To illustrate point 3:
consider that you have a command called "hello", and you put a call to
that command like "hel" in your script. This will work to begin with (if
you set tcl_interactive to 1), but if somebody else then adds a command
called "help", then your script is now ambiguous and will throw an error.
-- Neil
Michael Reichenbach
debug then errorInfo, there is also puts and such things. There are also
real debuggers which help you to step thought you source.
The only thing I can`t tell you is how to use a debugger if tcl is not
tclsh, but implemented into an program as script extending language with
an api.