what's wrong with <DATA>

[cyl]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

 

[Josef Moellers]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

Doesn't do it here. Maybe you

 

[Josef Moellers]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

Can't reproduce.
Maybe you have CR+LF in your file?

 

[Anno Siegel]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

You're running without "strict". Switch it on and declare your variables.
What is the variable $x for? You're not using it.

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

I don't see that output, it prints three lines as expected. What kind
of line feeds does your source file have and what are the settings of
$/ and $\?

Anno

 

[axel]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

It doesn't on my system. Maybe you have some non-printing characters
embedded after the 'txt' portion of each datum.

Axel

 

[Paul Lalli]

my script is as below

$i=1;
while(<DATA>){
$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

and the output is
1. 123.txt
2.
3. 456.txt
4.
5. 789.txt

Can anyone shed a light on why the extra blank appeared? Thanks.

I have no answers for you, but I will state that unlike the rest of the
responders, I did duplicate your issue. Under Windows 2000
Professional and ActiveState's Perl 5.8.4, the following code (modified
from the above to agree with the Posting Guidelines),

#!/usr/bin/perl
use strict;
use warnings;

my $i = 1;
while (<DATA>) {
chomp;
print "$i: '$_'\n";
$i++;
my $x = qx"dir $_";
}

__DATA__
123.txt
456.txt
789.txt

gave the same output as above. (Except that mine also printed three
"file not founds" because I didn't have those three files).

Very interesting to note is that after I duplicated your problem and
couldn't explain why, I rebooted my computer for an unrelated reason.
I just went back to the same program, without modifying anything, and
now the code works as I expect it to. I get three lines of output,
plus the File Not Founds.

I have no idea what was the original cause of the problem, but the fact
that a reboot solved it leads me to blame Windows in general. I'm
sorry I can't offer more assistance than that.

Paul Lalli

 

[cyl]

My script is written in Windows so it has CRLF in the end of a line. I
tested it again in both Windows and Linux and only got this problem in
Windows. If I convert the CRLF to LF, the problem disappears. Another
interesting thing to me is that if I comment the system call, the
problem won't happen either even with CRLF in the end. Like this

$i=1;
while(<DATA>){
#$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

output is
1. 123.txt
2. 456.txt
3. 789.txt

so there might be something during the system call that affect the file
handle DATA?

 

[Brad Murray]

c> My script is written in Windows so it has CRLF in the end of a line. I
c> tested it again in both Windows and Linux and only got this problem in
c> Windows. If I convert the CRLF to LF, the problem disappears. Another
c> interesting thing to me is that if I comment the system call, the
c> problem won't happen either even with CRLF in the end. Like this
c>
c> $i=1;
c> while(<DATA>){

chomp;

c> #$x=`dir $_`;
c> print $i++.". $_";
c> }
c> __DATA__
c> 123.txt
c> 456.txt
c> 789.txt

Why not chomp your data if you don't want the newlines? No matter how
you slice it, the newlines are probably not intended to be part of
your filenames, so why try to make things work with them intact?

 

[Josef Moellers]

My script is written in Windows so it has CRLF in the end of a line. I
tested it again in both Windows and Linux and only got this problem in
Windows. If I convert the CRLF to LF, the problem disappears. Another
interesting thing to me is that if I comment the system call, the
problem won't happen either even with CRLF in the end. Like this

$i=1;
while(<DATA>){
#$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

output is
1. 123.txt
2. 456.txt
3. 789.txt

so there might be something during the system call that affect the file
handle DATA?

Not being a conoisseur of the software that comes from the northwest of
the US, I venture to put it the other way round: Maybe the DATA
containing CRLFs affects the working of the backticks operation?

Like: `dir 123.txt<CR><LF>` causes two operations to happen:
- execute "dir 123.txt"
- echo CRLF

 

[Ch Lamprecht]

cyl wrote:

Not being a conoisseur of the software that comes from the northwest of
the US, I venture to put it the other way round: Maybe the DATA
containing CRLFs affects the working of the backticks operation?

Like: `dir 123.txt<CR><LF>` causes two operations to happen:
- execute "dir 123.txt"
- echo CRLF

The backticks work as expected. The question is: why do the backticks
change the behaviour of <DATA>...

use warnings;
use strict;
while(<DATA>){
` `;
print "$. $_";
}
__DATA__
123.txt
456.txt
789.txt

On WinXP, -in case the file has CRLF EOLs- this prints:

1 123.txt
2
3 456.txt
4
5 789.txt

In case the file has LF EOLs or with backticks commented out it prints:
1 123.txt
2 456.txt
3 789.txt

Christoph

 

[Dr.Ruud]

Ch Lamprecht schreef:

[backticks change the behaviour of <DATA>]
On WinXP, -in case the file has CRLF EOLs- this prints:

1 123.txt
2
3 456.txt
4
5 789.txt

Looks like an implicit (lexical/local?) 'binmode' is performed, if
backticks.

 

[Josef Moellers]

My script is written in Windows so it has CRLF in the end of a line. I
tested it again in both Windows and Linux and only got this problem in
Windows. If I convert the CRLF to LF, the problem disappears. Another
interesting thing to me is that if I comment the system call, the
problem won't happen either even with CRLF in the end. Like this

$i=1;
while(<DATA>){
#$x=`dir $_`;
print $i++.". $_";
}
__DATA__
123.txt
456.txt
789.txt

output is
1. 123.txt
2. 456.txt
3. 789.txt

so there might be something during the system call that affect the file
handle DATA?

What happens if you leave out the "print", or redirect it into another
file (print STDERR ..., then redirect stderr into another file)?

 

[Dr.Ruud]

Ch Lamprecht schreef:

` `;

Backticks in a void context, could be another special case as well.

 

[Ch Lamprecht]

Ch Lamprecht schreef:

[backticks change the behaviour of <DATA>]
On WinXP, -in case the file has CRLF EOLs- this prints:

1 123.txt
2
3 456.txt
4
5 789.txt

Looks like an implicit (lexical/local?) 'binmode' is performed, if
backticks.

It does not seem to be a matter of scope- this one still shows the same
output:

use warnings;
use strict;
while(<DATA>){
b_t();
print "$. $_";
}
sub b_t{
` `;
#system ('echo test');
}
__DATA__
123.txt
456.txt
789.txt

You can as well replace the backticks with a system call - that won't
change anything ether.

Christoph