From @smpeters

While testing some Perl code, I discovered that the undocumented behavior of
"print FILEHANDLE" DWIM, and prints $_ to the filehandle I specified. For
example​:

  perl -wle'$_="Does this work\n"; print STDERR'

prints $_ to STDERR. However, bracketing the filehandle returns a syntax
error.

  perl -wle'$_="does this work"; print {STDERR}'
  syntax error at -e line 1, at EOF
  Execution of -e aborted due to compilation errors.

Since this is undocumented, I'm guessing its not used much. Ideally, though,
this functionality should probably be fixed and documented.

From @smpeters

[stmpeters - Sun Nov 06 16​:22​:42 2005]​:

While testing some Perl code, I discovered that the undocumented
behavior of
"print FILEHANDLE" DWIM, and prints $_ to the filehandle I specified.
For
example​:

perl \-wle'$\_="Does this work\\n"; print STDERR'

prints $_ to STDERR. However, bracketing the filehandle returns a
syntax
error.

perl \-wle'$\_="does this work"; print \{STDERR\}'
syntax error at \-e line 1\, at EOF
Execution of \-e aborted due to compilation errors\.

Since this is undocumented, I'm guessing its not used much. Ideally,
though,
this functionality should probably be fixed and documented.

It appears that B​::Deparse is also unprepared for this syntax.

perl -MO=Deparse -wle'$_="foo"; print STDERR;'
BEGIN { $^W = 1; }
BEGIN { $/ = "\n"; $\ = "\n"; }
$_ = 'foo';
print STDERR $_;
-e syntax OK
perl -MO=Deparse -wle'$_="foo"; print {STDERR};'
syntax error at -e line 1, near "};"
-e had compilation errors.
BEGIN { $^W = 1; }
BEGIN { $/ = "\n"; $\ = "\n"; }
$_ = 'foo';
Use of uninitialized value in split at /usr/libdata/perl5/i386-openbsd/5.8.6/B/Deparse.pm
line 795.

@smpeters - Status changed from 'new' to 'open'

From @rgarcia

On 11/7/05, via RT Steve Peters <perlbug-followup@​perl.org> wrote​:

perl \-wle'$\_="does this work"; print \{STDERR\}'
syntax error at \-e line 1\, at EOF
Execution of \-e aborted due to compilation errors\.

Since this is undocumented, I'm guessing its not used much. Ideally, though,
this functionality should probably be fixed and documented.

Glancing at perly.y, I don't think this is easily fixable without
weird side-effects. The indirect object notation is full of evils.

From @doy

Although the issue itself still exists, as of dee33c9 this behavior is
now documented in perlfunc​:

  If you're storing handles in an array or hash, or in general whenever
  you're using any expression more complex than a bareword handle or a
  plain, unsubscripted scalar variable to retrieve it, you will have to
  use a block returning the filehandle value instead, in which case the
  LIST may not be omitted

Is the actual behavior planned to be fixed, or can this issue be closed?

From @nwc10

On Sun, Jun 24, 2012 at 03​:28​:46PM -0700, Jesse Luehrs via RT wrote​:

Although the issue itself still exists, as of dee33c9 this behavior is
now documented in perlfunc​:

If you're storing handles in an array or hash\, or in general whenever
you're using any expression more complex than a bareword handle or a
plain\, unsubscripted scalar variable to retrieve it\, you will have to
use a block returning the filehandle value instead\, in which case the
LIST may not be omitted

Is the actual behavior planned to be fixed, or can this issue be closed?

I don't think that you hit the right documentation. I think that the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

Nicholas Clark

From @doy

On Tue, Jul 03, 2012 at 10​:15​:59AM +0100, Nicholas Clark wrote​:

On Sun, Jun 24, 2012 at 03​:28​:46PM -0700, Jesse Luehrs via RT wrote​:

Although the issue itself still exists, as of dee33c9 this behavior is
now documented in perlfunc​:

If you're storing handles in an array or hash\, or in general whenever
you're using any expression more complex than a bareword handle or a
plain\, unsubscripted scalar variable to retrieve it\, you will have to
use a block returning the filehandle value instead\, in which case the
LIST may not be omitted

Is the actual behavior planned to be fixed, or can this issue be closed?

I don't think that you hit the right documentation. I think that the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

That documentation says that the LIST may not be omitted if you use a
block rather than just the bare filehandle.

-doy

From @cpansprout

On Tue Jul 03 02​:16​:31 2012, nicholas wrote​:

I don't think that you hit the right documentation. I think that the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

Work, or ‘work’? print STDERR is a hack. print STDERR $foo is
determined to have a filehandle during lexing, but print STDERR during
compilation.

So these all print $_ to STDERR​:

  print + STDERR;
  print +(STDERR);
  print + + + + + + (((((+(((+((STDERR))))))))));

--

Father Chrysostomos

From [Unknown Contact. See original ticket]

On Tue Jul 03 02​:16​:31 2012, nicholas wrote​:

I don't think that you hit the right documentation. I think that the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

Work, or ‘work’? print STDERR is a hack. print STDERR $foo is
determined to have a filehandle during lexing, but print STDERR during
compilation.

So these all print $_ to STDERR​:

  print + STDERR;
  print +(STDERR);
  print + + + + + + (((((+(((+((STDERR))))))))));

--

Father Chrysostomos

From @jkeenan

On Tue Jul 03 13​:00​:19 2012, sprout wrote​:

On Tue Jul 03 02​:16​:31 2012, nicholas wrote​:

I don't think that you hit the right documentation. I think that the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

Work, or ‘work’? print STDERR is a hack. print STDERR $foo is
determined to have a filehandle during lexing, but print STDERR during
compilation.

So these all print $_ to STDERR​:

print \+ STDERR;
print \+\(STDERR\);
print \+ \+ \+ \+ \+ \+ \(\(\(\(\(\+\(\(\(\+\(\(STDERR\)\)\)\)\)\)\)\)\)\);

doy, nicholas, Father C​:

Can we come to some kind of resolution on this issue so that we can
close the ticket?

Thank you very much.
Jim Keenan

From @cpansprout

On Fri Sep 21 19​:50​:46 2012, jkeenan wrote​:

On Tue Jul 03 13​:00​:19 2012, sprout wrote​:

On Tue Jul 03 02​:16​:31 2012, nicholas wrote​:

I don't think that you hit the right documentation. I think that
the bug
really is this​:

$ perl -le '$_ = "Pie"; print STDERR'
Pie
$ perl -le '$_ = "Pie"; print {STDERR}'
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl -le 'print STDERR "Pie"'
Pie
$ perl -le 'print {STDERR} "Pie"'
Pie

Why is the second a syntax error when the other three work?

Work, or ‘work’? print STDERR is a hack. print STDERR $foo is
determined to have a filehandle during lexing, but print STDERR during
compilation.

So these all print $_ to STDERR​:

print \+ STDERR;
print \+\(STDERR\);
print \+ \+ \+ \+ \+ \+ \(\(\(\(\(\+\(\(\(\+\(\(STDERR\)\)\)\)\)\)\)\)\)\);

doy, nicholas, Father C​:

Can we come to some kind of resolution on this issue so that we can
close the ticket?

We need to decide whether it is worth extending the implicit $_ to
print-BLOCK. I’m sure it’s doable, but it is documented not to work.

I think the examples I gave should definitely be fixed. That trips me
up in one-liners all the time.

However, this is not very close to the top of my to-do list.

--

Father Chrysostomos