I have a number of tests that spawn a child process - it is a binary outside my control. I'm using processman::spawn, but it could easily be just 'exec'.
This process prints something to stderr.
While I was using -singleproc 1, this wasn't a problem. However, later I realized that in this mode, global variables created by one .test script will be inherited by other .test scripts. So, I decided to switch to -singleproc 0 (that is the default anyway). And suddenly I end up with test reports like this:

Test file error: <stderr output from my child process>
....
Tests ended at Wed Nov 23 11:30:44 CET 2022
all.tcl: Total 9 Passed 9 Skipped 0 Failed 0
Sourced 1 Test Files.
Test files exiting with errors:
pubsub.test
also $? is 1.
So, tcltest believes that some tests failed just because they happen to print something to stderr!
I looked in the source code, and it doesn't look like I can configure this behaviour, because in essence it is:
if {!$singleProcess} {
catch { open shell } error

So, apparently 'open' throws an error and then catch's handler counts the test as failed.

could somebody point me to how I can avoid this?
thanks in advance

* Petro Kazmirchuk <petro.kazmirchuk@gmail.com>
| So, tcltest believes that some tests failed just because they happen to print something to stderr!
| I looked in the source code, and it doesn't look like I can configure this behaviour, because in essence it is:
| if {!$singleProcess} {
| catch { open shell } error
>
| So, apparently 'open' throws an error and then catch's handler counts the test as failed.

I expect rather the 'close' call for the pipe to fail if there is output
on stderr.

| could somebody point me to how I can avoid this?

Redirect stderr to some file, and inspect that file if the process
really fails (i.e. errorCode = childStatus)? Clumsy, I know...

R'

sorry, ofc you're right, it's 'close' that throws the error
well, I don't *really* need to see stderr (it would be nice to have though), so I'll just redirect it to /dev/null

On Wed, 23 Nov 2022 03:24:07 -0800 (PST)
Petro Kazmirchuk <petro.kazmirchuk@gmail.com> wrote:

> I have a number of tests that spawn a child process - it is a binary outside my control. I'm using processman::spawn, but it could easily be just 'exec'.
> This process prints something to stderr.
> While I was using -singleproc 1, this wasn't a problem. However, later I realized that in this mode, global variables created by one .test script will be inherited by other .test scripts. So, I decided to switch to -singleproc 0 (that is the default anyway). And suddenly I end up with test reports like this:
>
> Test file error: <stderr output from my child process>
> ...
> Tests ended at Wed Nov 23 11:30:44 CET 2022
> all.tcl: Total 9 Passed 9 Skipped 0 Failed 0
> Sourced 1 Test Files.
> Test files exiting with errors:
> pubsub.test
> also $? is 1.
> So, tcltest believes that some tests failed just because they happen to print something to stderr!
> I looked in the source code, and it doesn't look like I can configure this behaviour, because in essence it is:
> if {!$singleProcess} {
> catch { open shell } error
>
> So, apparently 'open' throws an error and then catch's handler counts the test as failed.
>
> could somebody point me to how I can avoid this?
> thanks in advance

You can get stdout and stderr from the child process using [chan pipe].
The magic incantation is

lassign [chan pipe] ir iw
lassign [chan pipe] er ew
exec {*}[list $progname $param1 $param2 ...] >@ $iw 2>@ $ew
chan close $iw
chan close $ew

Now you can use either [chan read] or [chan gets] to get the child process
data from $ir and $er handlers.

Regards

--
Emiliano Gavilán

* Emiliano Gavilán <emilianogavilan@gmail.com>
| You can get stdout and stderr from the child process using [chan pipe].
| The magic incantation is
>
| lassign [chan pipe] ir iw
| lassign [chan pipe] er ew
| exec {*}[list $progname $param1 $param2 ...] >@ $iw 2>@ $ew
| chan close $iw
| chan close $ew
>
| Now you can use either [chan read] or [chan gets] to get the child process
| data from $ir and $er handlers.

Cool trick, thanks for pointing that out!

However, if large amount of data is produced (notably more than the OS
pipes buffer) there is a chance of deadlock here, since TCL waits for
the 'exec' to finish, while the exec'd process might be blocked waiting
for the pipe to be read, no? (I think this could be avoided by using
[open |$cmd 2>@...] with only the pipe for stderr.)

R'

On Fri, 25 Nov 2022 11:30:22 +0100
Ralf Fassel <ralfixx@gmx.de> wrote:

> * Emiliano Gavilán
> | You can get stdout and stderr from the child process using [chan pipe].
> | The magic incantation is
> >
> | lassign [chan pipe] ir iw
> | lassign [chan pipe] er ew
> | exec {*}[list $progname $param1 $param2 ...] >@ $iw 2>@ $ew
> | chan close $iw
> | chan close $ew
> >
> | Now you can use either [chan read] or [chan gets] to get the child process
> | data from $ir and $er handlers.
>
> Cool trick, thanks for pointing that out!
>
> However, if large amount of data is produced (notably more than the OS
> pipes buffer) there is a chance of deadlock here, since TCL waits for
> the 'exec' to finish, while the exec'd process might be blocked waiting
> for the pipe to be read, no? (I think this could be avoided by using
> [open |$cmd 2>@...] with only the pipe for stderr.)

You can launch the child process in the background adding a trailing "&"
to the [exec] line.

- exec {*}[list $progname $param1 $param2 ...] >@ $iw 2>@ $ew
+ exec {*}[list $progname $param1 $param2 ...] >@ $iw 2>@ $ew &

This also allows for [chan event] to be used for both $ir and $er.

You can find more details on using [chan pipe] in the tip itself

https://core.tcl-lang.org/tips/doc/trunk/tip/304.md

and in the wiki

https://wiki.tcl-lang.org/page/chan+pipe

Regards

--
Emiliano Gavilan