Ticket UUID: | 1643952 | |||
Title: | CommRunHook evaluates event hooks twice | |||
Type: | Bug | Version: | None | |
Submitter: | cbascom | Created on: | 2007-01-24 23:38:28 | |
Subsystem: | comm | Assigned To: | andreas_kupries | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2007-01-26 00:11:14 | |
Resolution: | Out of Date | Closed By: | andreas_kupries | |
Closed on: | 2007-01-25 17:11:14 | |||
Description: |
It seems there was a change between the 4.3 and 4.4 versions to execute event hooks from CommRunHook instead of inside each of the individual event procs. Inside CommRunHook, the event callback is executed using 'eval $cmd'. Because of this, some of the variables advertised as being in scope for the callback script are not in scope (i.e. for a connect event fid, addr, and remport). Replacing the 'eval $cmd' line inside CommRunHook with 'uplevel 1 $cmd' fixes this issue. | |||
User Comments: |
andreas_kupries added on 2007-01-26 00:11:14:
Logged In: YES user_id=75003 Originator: NO This is fixed in the CVS. See the ChangeLog, entry below. 2006-11-29 Andreas Kupries <[email protected]> * comm.tcl (commRunHook): Fixed double execution of the hook script. Thanks to Will Duquette for the report. cbascom added on 2007-01-25 21:58:55: Logged In: YES user_id=1600284 Originator: YES The above description did indeed fix the out of scope variables issue, but I hadn't realized until now that the event hooks were getting evaluated twice. The first time they are evaluated is inside the if/else clause that checks to see whether another interpreter is in use or not. In this case, the uplevel 1 was used when evaluating in the current interpreter so variables were indeed in scope. The same event hook is then evaluated a second time by the eval command just below that if/else clause and at that point the variables are out of scope. I believe the fix is simply to remove that eval. |
