Front page | perl.perl5.porters |
Postings from October 2021
* Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> [2021-10-22 16:19:29 +0100]:
> On Fri, 22 Oct 2021 23:11:38 +0800
> Tom Molesworth via perl5-porters <perl5-porters@perl.org> wrote:
>
> > On Fri, 22 Oct 2021 at 22:50, Paul "LeoNerd" Evans
> > <leonerd@leonerd.org.uk> wrote:
> >
> > > I propose the addition of a new perlvar; perhaps named
> > >
> > > {
> > > local ${^OUTPUT_HANDLE} = $newh;
> > > print "Things";
> > > }
> > >
> >
> > Wouldn't the existing STDOUT local() support be more clear for this
> > case? It also has the advantage of working equivalently for
> > STDERR/warn:
> >
> > {
> > local *STDOUT = $newh;
> > print "Redirected";
> > }
> > {
> > local *STDERR = $newh;
> > warn "Also redirected";
> > }
> >
> > Or is this aimed more at format-related functionality?
>
> Wow. I had actually forgotten you can do that.
>
> Turns out that's perfectly fine for my use-case, which was a small
> unit-test around a print'ing method. I shall do that instead.
>
>
> The prosecution rests, your Honour.
If the net effect is that you can more clearly make a current script
"print" into different file handle by redefining what's used implicitly
via C<print> (STDOUT) or C<warn> (STDERR), then that might be handy.
I've also run into required gymnastics when wanting to both pipe STDIN
into a script *and* provide a means for interactive input, e.g.:
% ./dostuff.pl < input.file
and dostuff.pl *wants* to be able to have the following,
while (<>) {
# do something with $_
...
print "found X, proceed? (Y/n)\n";
my $ans = <STDIN>;
...
}
Anyway, just a thought. I might have read this whole thread wrong so pardon
me if I did.
Cheers,
Brett
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Thread Previous
|
Thread Next