That is what pipes are for!

Create a pipe, prevent it from being closed on exec, get the FD of it, then use 2>&$FD on the command line and you can read from the pipe to read the command's STDERR.

Something like this; not just untested, I've never done anything like this before (: ...

    {   local($^F)= 0x8000;
        pipe( READERR, WRITEERR ) or die "pipe: $!";
    }
    my $fd= fileno(WRITEERR);
    Expect->new( "command 2>&$fd" );
    close(WRITEERR);
[download]

I'd probably do this using fcntl() instead of $^F so that I could have READERR closed on exec while WRITEERR stays open.

To interleave the reading from the pipe with the use of Expect, it would probably be best to extend the expect() function to allow an extra file handle to be passed to the select() and return with a special code when that file handle gets some data. And if you're going to extend the expect() function, you could also extend the spawn() function so that it has an option to dup WRITEERR (instead of the new STDOUT) to STDERR.

<RANT> Why the h*** does Expect do a exec join(' ',@_) instead of just exec @_? Why get passed the arguments pre-parsed if you're just going to smash them all together and force the shell to reinterpret them! If I wanted to have the shell mess up my command line, I'd pass it in as a single string, the way Larry intended!</RANT>

        - tye (but my friends call me "Tye")