From: Brian Candler <B.Candler@...>
Date: 2003-05-03T06:57:59+09:00
Subject: Re: temporary redirection of stdout

On Sat, May 03, 2003 at 04:07:42AM +0900, ahoward wrote:
> On Fri, 2 May 2003, Robert wrote:
> 
> > Err, why are you surprised?  This is exactly what I would have expected
> > since $defout, $stdout and STDOUT initially point to the same instance.  So
> > it doesn't really matter on which of the instances you do issue 'reopen',
> > they "all" get redirected.
> 
> i'm suprised since STDOUT has the semantics of being a constant (i realize
> that the object it points to is not constant).  i would have *thought* that
> changing $stdout (a *variable*) would not of changed STDOUT.

But you didn't change the variable $stdout; you called $stdout.reopen (well,
$defout.reopen actually, but they were pointing at the same object)

> all i'm saying
> is of what value (in terms of POLS) is it to provied the constant STDOUT *and*
> the variable $stdout, when in fact *both* are 'variable'.

I don't think it's any different to:

    I_AM_A_CONSTANT = []

    I_AM_A_CONSTANT << "element"

    p I_AM_A_CONSTANT   #>> ["element"]

The sense of "constant" is "this identifier cannot be changed to point to a
different object", but that doesn't stop you calling methods which change
its internal state.

If you change the state of the process's stdout using $stdout.close or
$stdout.reopen, I don't think you can't get back what it was originally
connected to (and it doesn't really make sense - e.g. if something had been
listening to your process's stdout via a pipe, it would have seen the pipe
closed).

Regards,

Brian.