Tcl Source Code

View Ticket
Login
Ticket UUID: 77527e2f990734b412f956a33d3b4d026d0e3ac7
Title: Tcltest disregards output from child interpreters
Type: Bug Version: 2.2
Submitter: erikleunissen Created on: 2021-01-13 19:19:18
Subsystem: 34. tcltest Package Assigned To: jan.nijtmans
Priority: 5 Medium Severity: Important
Status: Open Last Modified: 2021-01-22 21:34:57
Resolution: None Closed By: nobody
    Closed on:
Description:
If a Tcl application uses child interpreters that write to stdout or stderr, tcltest doesn't capture the output as it does for regular interpreters.

The attached script script exercises the behaviour.
Test output when I run it:

% ./exercise.tcl
Hi from child.
Error message from child.


==== someProc-1.1 capture output from child interp FAILED
==== Contents of test case:

        someProc

---- Output was:

---- Output should have been (exact matching):
Hi from child.

---- Error output was:

---- Error output should have been (exact matching):
Error message from child.

==== someProc-1.1 FAILED

exercise.tcl:   Total   1       Passed  0       Skipped 0       Failed  1
User Comments: erikleunissen added on 2021-01-22 21:34:57:
 .. that is: to be fixed in tcltest

erikleunissen added on 2021-01-22 21:33:38:
Uhmm,

Maybe my text was ambiguous, but:

@Jan: do you see this issue as a shortcoming of tcltest ?

erikleunissen added on 2021-01-14 17:24:30:
Hi Jan,

Yes I do have very rough idea's. But these are quite imaginary because I didn't investigate the code for tcltest, and I don't know what mechanism it uses for capturing output to std channels.

Not by carelessness or so; but I find the whole situation in which I experience this issue difficult to assess because:

a. This is a case where a fix would need to choose a way to transfer output over the boundary between the parent and child interpreter. I think that that is technically possible (interp aliases come to mind), but it is also conditional: for stdout and stderr only.

b. It's exactly this area where I find the documentation of tcltest inadequate: it uses the terms "interpreter" and "process" in a way that confuses me. It seems to disregard the difference between them. And I might add the term "executable" to the collection. That's why I'm very, very cautious right now. I even think of the possibility that tcltest was not intended for testing aspects that involve multiple interpreters, but that it just fails to make that clear.


Therefore, before going into details about how to possibly fix this, I would first make clear what we should expect from tcltest, and what we expect from the cases employing tcltest in tis specific respect. That should make clear whether the "fix" is needed in tcltest, or whether the user should apply the fix to his own case. At the same time we should clear up the confusion about the terminology for our own understanding within this ticket (actually this is *my* confusion, maybe you don't see it that way).

As a next step, I'm willing to do a further investigation about how to implement this. I have a use case and a need anyway, but depending on where to fix this, it might involve quite a different amount of work.

If we come to the conclusion that we need to accept this as a limitation of tcltest, and let the user cope with it, then I'd suggest to change the tcltest docs:
- clear up the confusion with the terminology in the docs, regardless.
- make the limitation presented in this ticket explicit
- maybe add a suggestion of how to overcome this limitation

jan.nijtmans added on 2021-01-14 10:16:00:

Erik, any idea how to fix this?


Attachments: