From schuller@lunatech.com

I've found a bug in interpolation of $_ when followed by the characters [] .

$ perl5.00503 -e '$_="a"; print "${_}[]\n"'
a[]
$ perl5.00562 -e '$_="a"; print "${_}[]\n"'
[]

Leaving off the curlies gives

$ perl5.00562 -e '$_="a"; print "$_[]\n"'
syntax error at -e line 1, near "[]"
Execution of -e aborted due to compilation errors.

So I don't know how to follow $_ with literal square brackets other than
concatenating two different strings.

Site configuration information for perl 5.00562:

Configured by schuller at Sat Oct 16 13:14:32 CEST 1999.

Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
  Platform:
    osname=linux, osvers=2.2.9, archname=i686-linux-thread
    uname='linux sep 2.2.9 #17 sun may 16 16:29:28 cest 1999 i686 unknown '
    config_args='-des -Dprefix=/big/perl -Uinstallusrbinperl -Dusethreads -Ubincompat5005'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.95.2 19990906 (prerelease)
    cppflags='-D_REENTRANT -Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-D_REENTRANT -Dbool=char -DHAS_BOOL -fno-strict-aliasing -I/usr/local/include'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt
    libc=/lib/libc-2.1.2.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00562:
    /big/perl/lib/5.00562/i686-linux-thread
    /big/perl/lib/5.00562
    /big/perl/lib/site_perl/5.00562/i686-linux-thread
    /big/perl/lib/site_perl
    .


Environment for perl 5.00562:
    HOME=/home/schuller
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/opt/al/lib
    LOGDIR (unset)
    PATH=/home/schuller/bin:/opt/framerd/bin:/big/Isearch/bin:/big/mg/bin:/big/wine/bin:/kde/bin:/opt/bmrt/bin:/big/perl/bin:/big/tom/bin:/opt/java/bin:/usr/local/kde/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/ssl:/usr/games:/vmware/bin:/opt/al/bin
    PERL_BADLANG (unset)
    SHELL=/usr/bin/tcsh

From @tamias

On Fri, Dec 31, 1999 at 04​:23​:28PM +0100, Bart Schuller wrote​:

I've found a bug in interpolation of $_ when followed by the characters [] .

$ perl5.00503 -e '$_="a"; print "${_}[]\n"'
a[]

This is reasonable behavior.

$ perl5.00562 -e '$_="a"; print "${_}[]\n"'
[]

This is not reasonable behavior; I can't explain it. What happened to the
value of $_?

Leaving off the curlies gives

$ perl5.00562 -e '$_="a"; print "$_[]\n"'
syntax error at -e line 1, near "[]"
Execution of -e aborted due to compilation errors.

This is reasonable too. $_[] refers to the array @​_, but it's a syntax
error because the index is missing.

So I don't know how to follow $_ with literal square brackets other than
concatenating two different strings.

Escape the bracket with a backslash. In a double-quoted string, a
backslash followed by any non-word character is always interpolated as the
literal character.

print "$_\[]\n";

Ronald

From @TimToady

Bart Schuller writes​:
: I've found a bug in interpolation of $_ when followed by the characters [] .
:
: $ perl5.00503 -e '$_="a"; print "${_}[]\n"'
: a[]
: $ perl5.00562 -e '$_="a"; print "${_}[]\n"'
: []

This appears to be because you've got USE_THREADS defined. That tends
to lexicalize certain variables, which would tend to rule out lookup
via the symbol name. Except that ${_} should not be looked up at
runtime in any event. It has probably confused one or another of
the #ifdef USE_THREADS kludges, is my guess. I don't have a USE_THREADS
version compiled up here, so someone else will need to chase this down,
unless I get around to it first.

Note that we'd like to move to $_ being lexically scoped over the
long term, but probably only if you actually declare "my $_" up at
the top. On the other hand, a good argument could be made for
breaking global $_ unless you declare "our $_".

Larry

From [Unknown Contact. See original ticket]

Larry Wall <larry@​wall.org> wrote

This appears to be because you've got USE_THREADS defined. That tends
to lexicalize certain variables, which would tend to rule out lookup
via the symbol name. Except that ${_} should not be looked up at
runtime in any event. It has probably confused one or another of
the #ifdef USE_THREADS kludges, is my guess. I don't have a USE_THREADS
version compiled up here, so someone else will need to chase this down,
unless I get around to it first.

I can confirm that it doesn't fail on 5.005_62 without threads.

It seems like this is all pointing to a very long standing bug (or is it
a misfeature?) - the [] causes ${a} to be taken as global, not lexical​:

% perl5.002 -we '$a="b"; my $a="a"; print "${a}[]\n"'
b[]

%perl5.002 -we '$a="b"; my $a="a"; print "${a}\[]\n"'
a[]

Mike Guy