From: Robert Klemme <bob.news@...>
Date: 2003-05-05T17:56:50+09:00
Subject: Re: temporary redirection of stdout


"Brian Candler" <B.Candler@pobox.com> schrieb im Newsbeitrag
news:20030502215756.GA43281@uk.tiscali.com...
> 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.

Even worse, you *can* change the value but get a warning.  Or is there any
command line option that prevents value changes on constants?

> 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).

Exactly!

    robert