From ed_peschko@csgsystems.com

Site configuration information for perl 5.00561​:
Configured by epeschko at Tue Sep 7 16​:51​:28 MDT 1999.
Summary of my perl5 (revision 5.0 version 5 subversion 61) configuration​:
  Platform​:
  osname=solaris, osvers=2.5.1, archname=sun4-solaris
  uname='sunos den-mdev1 5.5.1 generic_103640-27 sun4u sparc sunw,ultra-enterp
rise '
  config_args='-ds -e -Dprefix=/home/epeschko/install -Dcc=/home/epeschko/inst
all/bin/gcc -Dcc='/home/epeschko/install/bin/gcc''
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  use64bits=undef usemultiplicity=undef
  Compiler​:
  cc='/home/epeschko/install/bin/gcc', optimize='-O', gccversion=2.95.1 199908
16 (release)
  cppflags='-I/usr/local/include'
  ccflags ='-I/usr/local/include'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='/home/epeschko/install/bin/gcc', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt -lsec
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E'
  cccdlflags='-fPIC', lddlflags=' -W,l-E -G -L/usr/local/lib'
Locally applied patches​:

@​INC for perl 5.00561​:
  /home/epeschko/install/lib/perl5/5.00561/sun4-solaris
  /home/epeschko/install/lib/perl5/5.00561
  /home/epeschko/install/lib/site_perl/5.00561/sun4-solaris
  /home/epeschko/install/lib/site_perl
  .

Environment for perl 5.00561​:
  HOME=/home/epeschko
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/usr/openwin/lib​:/opt/SUNWspro/lib​:/usr/local/epage/lib​:/net
/den-mleg1/export/sybase/lib​:/home/epeschko/install/lib​:/net/animas/export/third
-party/ora-vrs/ora734/lib
  LOGDIR (unset)
  PATH=/net/animas/opt/SUNWspro/bin​:/home/epeschko/migration_util/bin​:/home/ep
eschko/install/bin​:/home/epeschko/migtools/PROD/tools/team​:/home/epeschko/migtoo
ls/PROD/tools/migration​:/opt/SUNWspro/ParallelMake/bin​:/opt/SUNWspro/bin​:/usr/cc
s/bin​:/net/animas/opensys/dev/tools/bin​:/home/epeschko/install/bin​:/usr/bin​:/usr
/sbin​:/usr/openwin/bin​:/usr/ucb/bin​:.​:/bin​:/usr/ucb​:/usr/ucb​:/usr/ucb​:/usr/local
/bin​:/net/den-mdev1/export/datamig_dev/source_control/work/bin​:/usr/ucb​:/net/den
-mst1/export/sybase/sybase_11.0.2/bin/​:/net/den-mdev1/export/datamig_dev/tools
  PERL_BADLANG (unset)
  SHELL=/home/epeschko/install/bin/tcsh

From [Unknown Contact. See original ticket]

The following code​:

eval('
  a()
  $OOT = "/compile/epeschko1";
  $GLOBAL = " /compile/integrate/global";
  '
);

'leaks' its error message to the screen as a warning, even when '-w' is turned
off, as in​:

Scalar found where operator expected at (eval 1) line 3, near ")
  $OOT"
  (Missing operator before $OOT?)

When you put​:

$SIG{__WARN__} = sub {};

it stops doing so - but why does it print at all? Not sure this is a 'bug' per
say, but it sure smells, tastes, and acts like one...

Ed

(PS​: also noticed that the '#line 7' syntax does not work with eval, ie​: if you
say

#line 10
a()
b()

then the error is still reported at line #2. Not sure if this is a bug either
but it would be a nice to have....
)

Site configuration information for perl 5.00561:
Configured by epeschko at Tue Sep  7 16:51:28 MDT 1999.
Summary of my perl5 (revision 5.0 version 5 subversion 61) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos den-mdev1 5.5.1 generic_103640-27 sun4u sparc sunw,ultra-enterp
rise '
    config_args='-ds -e -Dprefix=/home/epeschko/install -Dcc=/home/epeschko/inst
all/bin/gcc -Dcc='/home/epeschko/install/bin/gcc''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
    use64bits=undef usemultiplicity=undef
  Compiler:
    cc='/home/epeschko/install/bin/gcc', optimize='-O', gccversion=2.95.1 199908
16 (release)
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='/home/epeschko/install/bin/gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt -lsec
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E'
    cccdlflags='-fPIC', lddlflags=' -W,l-E -G -L/usr/local/lib'
Locally applied patches:



@INC for perl 5.00561:
    /home/epeschko/install/lib/perl5/5.00561/sun4-solaris
    /home/epeschko/install/lib/perl5/5.00561
    /home/epeschko/install/lib/site_perl/5.00561/sun4-solaris
    /home/epeschko/install/lib/site_perl
    .

Environment for perl 5.00561:
    HOME=/home/epeschko
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/openwin/lib:/opt/SUNWspro/lib:/usr/local/epage/lib:/net
/den-mleg1/export/sybase/lib:/home/epeschko/install/lib:/net/animas/export/third
-party/ora-vrs/ora734/lib
    LOGDIR (unset)
    PATH=/net/animas/opt/SUNWspro/bin:/home/epeschko/migration_util/bin:/home/ep
eschko/install/bin:/home/epeschko/migtools/PROD/tools/team:/home/epeschko/migtoo
ls/PROD/tools/migration:/opt/SUNWspro/ParallelMake/bin:/opt/SUNWspro/bin:/usr/cc
s/bin:/net/animas/opensys/dev/tools/bin:/home/epeschko/install/bin:/usr/bin:/usr
/sbin:/usr/openwin/bin:/usr/ucb/bin:.:/bin:/usr/ucb:/usr/ucb:/usr/ucb:/usr/local
/bin:/net/den-mdev1/export/datamig_dev/source_control/work/bin:/usr/ucb:/net/den
-mst1/export/sybase/sybase_11.0.2/bin/:/net/den-mdev1/export/datamig_dev/tools
    PERL_BADLANG (unset)
    SHELL=/home/epeschko/install/bin/tcsh

From [Unknown Contact. See original ticket]

On Sun, 03 Oct 1999 at 01​:10​:45 -0000, richard@​tmtowtdi.perl.org wrote​:

(PS​: also noticed that the '#line 7' syntax does not work with eval, ie​: if you
say

#line 10

The syntax is

  #line 10 "foo"

I.e. you need a 'file name' too. It's also the case that a #line won't
be recognised if it's the first line of an eval. I regard this as a
minor bug, which I haven't up to now thought worth reporting.

I've found that interpolating qq{\nline 1 "$name"\n} does the trick.

Ian

From [Unknown Contact. See original ticket]

I note that this bug report (as received by p5p) has

From​: richard@​tmtowtdi.perl.org

but lower down we see the suspicious

  $OOT = "/compile/epeschko1";

Is this message really from Richard or from Ed ?

Has the old replacing From​: lines bug resurfaced? Or is it just
my paranoia cutting in?

And other oddities​:

a) The ID is [ID 19991002.015], i.e. issued on 2nd Oct, but we see
  Date​: 3 Oct 1999 01​:10​:45 -0000

  A timezone effect?

b) Although the ID is the 15th issued on 2nd Oct, neither I nor the
  p5p archive have seen numbers 1-14.

Mike Guy

From @gsar

On Sun, 03 Oct 1999 09​:47​:24 BST, Ian Phillipps wrote​:

On Sun, 03 Oct 1999 at 01​:10​:45 -0000, richard@​tmtowtdi.perl.org wrote​:

(PS​: also noticed that the '#line 7' syntax does not work with eval, ie​: if
you
say

#line 10

The syntax is

#line 10 "foo"

I.e. you need a 'file name' too.

Not true. If you don't supply the filename it defaults to the
scriptname, aka $0.

                             It's also the case that a \#line won't

be recognised if it's the first line of an eval. I regard this as a
minor bug, which I haven't up to now thought worth reporting.

This is probably what's biting them.

Sarathy
gsar@​activestate.com

From [Unknown Contact. See original ticket]

On Sun, Oct 03, 1999 at 09​:47​:24AM +0100, Ian Phillipps wrote​:

On Sun, 03 Oct 1999 at 01​:10​:45 -0000, richard@​tmtowtdi.perl.org wrote​:

(PS​: also noticed that the '#line 7' syntax does not work with eval, ie​: if you
say

#line 10

The syntax is

#line 10 "foo"

well, actually both syntaxes work - ie​: if you say

#line 10

it takes the current file as filename.

Ed

From [Unknown Contact. See original ticket]

On Mon, 04 Oct 1999 at 10​:59​:51 -0500, Ed Peschko wrote​:

On Sun, Oct 03, 1999 at 09​:47​:24AM +0100, Ian Phillipps wrote​:

On Sun, 03 Oct 1999 at 01​:10​:45 -0000, richard@​tmtowtdi.perl.org wrote​:
It was you, Ed, wasn't it?

(PS​: also noticed that the '#line 7' syntax does not work with eval, ie​: if you
say
#line 10

The syntax is
#line 10 "foo"

well, actually both syntaxes work - ie​: if you say

#line 10
it takes the current file as filename.

Hmm.. looks like a bug to me. Can't it be arranged so that the file name
doesn't change. If you do an eval, it says so, but if the eval has
"\n#line 10" in it, it resets to line 10 *of the main script* (as
pointed out implicitly by Sarathy in a parallel posting).
This applies, too, to stuff that's C<require>d. Bug! Bug!

So, in a way, I'll stand by my original comment, erroneous as it was​:
the syntax is #line 10 "foo" - if you omit the file name, you get
something that's almost certainly wrong (since use #line is almost never
going to be in the $0 script IMO).

Ian

From [Unknown Contact. See original ticket]

:-\

I note that this bug report (as received by p5p) has

From​: richard@​tmtowtdi.perl.org

but lower down we see the suspicious

$OOT = "/compile/epeschko1";

Is this message really from Richard or from Ed ?
You're right, having fixed the duplicate bug, I now claim all bugs as my
own..., well until I fix that newly introduced one, anyway, sorry.

Has the old replacing From​: lines bug resurfaced? Or is it just
my paranoia cutting in?
I'm not sure whether you would be more paranoid than me, yet.

And other oddities​:

a) The ID is [ID 19991002.015], i.e. issued on 2nd Oct, but we see
Date​: 3 Oct 1999 01​:10​:45 -0000

A timezone effect?

Probably, I'll have a look into it.

b) Although the ID is the 15th issued on 2nd Oct, neither I nor the
p5p archive have seen numbers 1-14.
Eek.

Mike Guy
Thanks, I'm resurfacing.

Ciao
--
Richard Foley
+49 (0) 8121 988920 -> richard@​rfi.net

From @gsar

On Mon, 04 Oct 1999 18​:24​:16 BST, Ian Phillipps wrote​:

Hmm.. looks like a bug to me. Can't it be arranged so that the file name
doesn't change. If you do an eval, it says so, but if the eval has
"\n#line 10" in it, it resets to line 10 *of the main script* (as
pointed out implicitly by Sarathy in a parallel posting).
This applies, too, to stuff that's C<require>d. Bug! Bug!

So, in a way, I'll stand by my original comment, erroneous as it was​:
the syntax is #line 10 "foo" - if you omit the file name, you get
something that's almost certainly wrong (since use #line is almost never
going to be in the $0 script IMO).

The behavior is certainly not accidental--the implementation is quite
explicit. The intent may have been to make it so that code within
eval/require can pretend that it lived in the main script, which seems
like a useful thing.

But being able to alter just the line number would be useful too.
Perhaps we can support C<#line 10 __FILE__> or similar.

Sarathy
gsar@​activestate.com

From [Unknown Contact. See original ticket]

Ian Phillipps writes​:

(since use #line is almost never
going to be in the $0 script IMO).

I think on WIn* #line is almost always present in $0 scripts
(when wrapped in batch files).

Ilya

From [Unknown Contact. See original ticket]

From​: richard@​rfi.net [mailto​:richard@​rfi.net]

You're right, having fixed the duplicate bug, I now claim all
bugs as my own..., well until I fix that newly introduced one,
anyway, sorry.

You also seem to have lost the X-Loop identifying header from perlbug
messages. What can I filter on now to put perlbug messages in
a separate
folder?
Blast, it's got to be there and I don't know why it's come off.
I'll just have to go back and have another peek.

Ciao
Richard Foley

richard@​rfi.net
"Ciao" - (shorter than 'Aufwiedersehen' :-)

From @TimToady

Gurusamy Sarathy writes​:
: The behavior is certainly not accidental--the implementation is quite
: explicit. The intent may have been to make it so that code within
: eval/require can pretend that it lived in the main script, which seems
: like a useful thing.

Er, no, actually. Given that the #line code was done in order to
implement the -P switch using a variety of C preprocessors, it's
slightly accidental that it works in eval at all. As I recall, the
typical C preprocessor would bracket any #include with two #line
directives​:

  #line 10 "foo.h"
  ...
  #line 10 ""

But you'll also see other styles, such as

  # 10 "foo.h"
  ...
  # 10 ""

or

  #line 10 foo.h
  ...
  #line 10

Larry

From [Unknown Contact. See original ticket]

On Tue, 05 Oct 1999 at 11​:06​:19 -0700, Larry Wall wrote​:

Er, no, actually. Given that the #line code was done in order to
implement the -P switch using a variety of C preprocessors, it's
slightly accidental that it works in eval at all.

A very valuable feature, though. I have a script that concocts a dozen
or so evals (built from the command args, too :-), and it's nice to have
syntax errors telling me which one.

Ian

From [Unknown Contact. See original ticket]

This still appears to be true as of @​8221.

[Please enter your report here]
 
The following code​:
 
eval('
  a()
  $OOT = "/compile/epeschko1";
  $GLOBAL = " /compile/integrate/global";
  '
);
 
'leaks' its error message to the screen as a warning, even when '-w' is
turned off, as in​:
 
Scalar found where operator expected at (eval 1) line 3, near ")
  $OOT"
  (Missing operator before $OOT?)
 
When you put​:
 
$SIG{__WARN__} = sub {};
 
it stops doing so - but why does it print at all? Not sure this is a 'bug'
per say, but it sure smells, tastes, and acts like one...
 
Ed

From @tamias

On Thu, Dec 21, 2000 at 03​:39​:09PM -0500, Stephen P. Potter wrote​:

This still appears to be true as of @​8221.

[Please enter your report here]

The following code​:

eval('
a()
$OOT = "/compile/epeschko1";
$GLOBAL = " /compile/integrate/global";
'
);

'leaks' its error message to the screen as a warning, even when '-w' is
turned off, as in​:

Scalar found where operator expected at (eval 1) line 3, near ")
$OOT"
(Missing operator before $OOT?)

When you put​:

$SIG{__WARN__} = sub {};

it stops doing so - but why does it print at all? Not sure this is a 'bug'
per say, but it sure smells, tastes, and acts like one...

According to perldiag, "%s found where operator expected" is a severe
warning, and severe warnings are mandatory.

Ronald