Re^2: Assigning printf to a variable

pryrt very helpfully provided a snippet to redirect STDOUT over on Re^2: Errors uncaught by CGI::Carp

There, the >& file operator was used. I had come across this before but didn't properly understand it. So I looked it up and thought I understood. But, from my understanding I would have thought that Fletch's example should use open( my $fh, q{>&}, \$output ) or die "Problem redirecting to scalar: $!\n"; instead of the plain q{>}

What have I missed?

Comment on Re^2: Assigning printf to a variable Select or Download Code

Replies are listed 'Best First'.

Re^3: Assigning printf to a variable
by pryrt (Abbot) on Oct 20, 2021 at 14:43 UTC

Thanks for the mention. I'm not an expert on such things; I just learned more about it than I ever thought I would when I was trying to create tests for Games::Literati -- enough that I can muddle through it when I want to do in-memory filehandles and STDOUT duping. But I did have to muddle some before I got that example working.

Your open( my $fh, q{>&}, \$output ) or die "Problem redirecting to scalar: $!\n"; snippet is combining two concepts: there's the writing to an in-memory filehandle, which is the \$output portion; and there is the "duping" (duplicating) filehandles, which is the q{>&}. You can open a filehandle into the scalar variable like Fletch did without requiring the duping. In Re^2: Errors uncaught by CGI::Carp, I used duping on STDOUT because I had to grab the old version of STDOUT and then replace STDOUT with a new handle. If you look at that code again, you'll see the duping-& was only used on the opens that were dealing with STDOUT, not on the open for the in-memory filehandle. You'll want to keep the two concepts separate in your mind, otherwise you'll make things even more confusing for yourself (and will have a harder time muddling through than I did.)

[reply]
[d/l]
[select]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks