in reply to sub STDERR { *STDERR } -- nearly works !

If you run your first code through B::Deparse I don't think it's being parsed the way you think it is. But rather than playing games attempting to get something other than a bareword or block working in the filehandle slot, why not just use something along the lines of: open( my $stderr, ">&STDERR" ) or die "Can't dup STDERR: $!\n";?

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^2: sub STDERR { *STDERR } -- nearly works !
by gone2015 (Deacon) on Apr 08, 2008 at 19:59 UTC

    OK... print STDERR "....", ... is not being parsed as a file handle, but as a subroutine call with no brackets... for some reason I thought that required a prototype :-(

    The second version, with a () prototype clearly stops that happening.

    So the problem is that the subroutine-ness of the modified STDERR is taking precendence over the filehandle-ness -- which is a shame, really.

    There are, of course, any many ways of creating a $XXX version of STDERR... what I was hoping for was a way to tweak a FH so that it can appear equally in: print FH .... and p_sub(FH, ....).

    Because STDERR is visible everywhere, sub STDERR () { *STDERR } ; placed anywhere very nearly -- but not quite :-( -- does the job without every module needing to do, say, my $STDERR=*STDERR{IO} for itself.

    Chris