In our application we use ::tclreadline::Loop.
In a special case we can observe a strange behaviour at the line
set LINE [::tclreadline::readline read \
[::tclreadline::prompt1]]
The variable LINE gets the input typed at the prompt prefixed by the string "ok open", e.g. you
type in "puts" and get "ok openputs" -> invalid command name "ok". (This string "ok open" was
sent over a socket during execution of the previous command.)
I debugged the C code in tclreadline.c with gdb and found the following wrong behaviour
in TclReadlineLineCompleteHandler(char* ptr)
Before executing
Tcl_AppendResult(tclrl_interp, expansion, (char*) NULL);
(xxgdb) print *tclrl_interp
$9 = {
result = 0x23f78 "",
freeProc = 0,
errorLine = 1
}
This seems to be correct, but
print (char *)Tcl_GetString(Tcl_GetObjResult(tclrl_interp))
$5 = 0x489d60 "ok open"
shows already the pending problem - compare with the beginning of
Tcl_AppendResultVA (interp, argList) in the source code of tclResult.c.
After executing the mentioned Tcl_AppendResult statement:
(xxgdb) print *tclrl_interp
$10 = {
result = 0x2bc80 "ok openjj",
freeProc = 0,
errorLine = 1
}
(xxgdb) print expansion
$11 = 0x4aee28 "jj"
x/10cs 0x23f78
0x23f78: "ok open"
0x23f80: "unite/RegressionTest/ne1"
0x23f99:
I introduced the code lines
// Gottfried Lindner, 11.09.01
if (strcmp(tclrl_interp->result, "") == 0) {
Tcl_SetObjResult(tclrl_interp, Tcl_NewStringObj("",0));
}
before
Tcl_AppendResult(tclrl_interp, expansion, (char*) NULL);
This solved the problem, but is only intended as work-around. Is there a bug in
Tcl_AppendResultVA (interp, argList) in tclResult.c?
although this projects seems orphaned, I found a minimum working example. It is all about return values of procedures called in the Tcl main loop:
/tmp$ tclsh
% package require tclreadline
2.1.0
% ::tclreadline::Loop
tclsh8.5 [/tmp]after 1 {apply {args {return oops}}}
after#0
tclsh8.5 [/tmp]
invalid command name "oops"
while evaluating oops
tclsh8.5 [/tmp]
The result of apply is written into the line buffer. I guess that Expect is even more vulnerable there ...