Separating stdout and stderr

Christophe Lyon <[email protected]>
Newsgroups gmane.comp.sysutils.dejagnu.general
Message-ID <CAKdteOan0A5_c8uryt9gG=S=6wx6iXXu1_=Oct82WLdo4OZQ4A@mail.gmail.com>
Hi,

We suspect that the non-ordered nature of stdout vs stderr is causing
random problems in our GCC validations.

I wanted to experiment with forcing separation between stdout and
stderr, then concatenating them, but so far I haven't been able to
twist dejagnu to do so.


I wanted to make use of a function like "invoke" as defined in
http://wiki.tcl.tk/1241. I tried to call "invoke" instead of "spawn"
but it seems that $spawn_id is not set by "open", but this variable is
needed by dejagnu (local_exec in remote.exp).


Then, I thought I could force output redirection, hence using an
existing code-path in dejagnu (still in local_exec in remote.exp). To
this end, at the beginning of local_exec, if $outp is empty, I force
it to, say /tmp/foo.pid and set a flag to remember this later.
In the code handling the redirection, I replaced
set outp "> $outp"
with
set outp "> $outpf 2> ${outpf}.err"

Now before resuming the normal code-path, I need to execute "cat
$outpf ${outpf}.err" (if the flag I mentioned above is set):
set result [catch {open "| cat $outpf ${outpf}.err" "w"} id]

But I keep having errors in the expect statement a few lines later:
ERROR: bad spawn_id (process died earlier?)
    while executing
"expect {
        -i $spawn_id -timeout $timeout -re ".+" {
            append output $expect_out(buffer)
            if { [string length $output] < 512000 } {
                exp_contin..."
    (procedure "local_exec" line 117)

I hoped that the statement:
set result [catch "spawn -ignore SIGHUP -leaveopen $id" result2]

would setup $spawn_id and help building $output

I'm surely missing something obvious, but I'm not very fluent in tcl :(

I'd like to make this "work" and experiment with it to check if it
would make our validations more reliable.

Thanks,

Christophe.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.