* Zefram <zef...@fysh.org> [2015-07-19 20:35]:
> Aristotle Pagaltzis wrote:
> > There is no way I can think of doing this with the select-based
> > approach, nor with dup/reopen without involving XS;
>
> […] DESTROY on a blessed object […]
D’oh. Insufficient caffeine.
> Your "local *STDOUT" is a valid approach where applicable. Preferable to
> any End-like mechanism in those cases. It incidentally leaves *STDOUT{IO}
> empty, so that an explicit close is no longer required before the reopen.
Which is the whole point, of course: the original STDOUT FH for fd 1 sticks
around on the stack along with the rest of the glob and the FH in the fresh
glob gets opened with a different fd. So there’s no need to either close or
reopen fd 1 (which I was unaware has to happen in that order). Which is also
what makes the whole charade invisible at the libc level.
(Incidentally it can be onelinered: open local *STDOUT, '>', \(my $out = ''))
So to ask the question I was getting at but didn’t actually ask: given the
code in File::Path and James’ goal of re-/writing some tests for it, do you
consider this approach sufficient for the purpose?
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
