what's wrong with <DATA>
cyl
$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
Doesn't do it here. Maybe you
--
Josef Mo"llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
Josef Moellers
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
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
ax...@white-eagle.invalid.uk
It doesn't on my system. Maybe you have some non-printing characters
embedded after the 'txt' portion of each datum.
Axel
Paul Lalli
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
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?
--
Brad Murray * "This won't help relations. Marines taking over a Baghdad
VSCA Founder * hotel. [yelling]" -- CNN closed captioning error
Josef Moellers
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
--
Josef Möllers (Pinguinpfleger bei FSC)
Ch Lamprecht
> cyl wrote:
>> $i=1;
>> while(<DATA>){
>> #$x=`dir $_`;
>> print $i++.". $_";
>> }
>> __DATA__
>> 123.txt
>> 456.txt
>> 789.txt
>>
> 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
--
perl -e "print scalar reverse q/ed.e...@ergn.l.hc/"
Dr.Ruud
> [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.
--
Affijn, Ruud
"Gewoon is een tijger."
Josef Moellers
What happens if you leave out the "print", or redirect it into another
file (print STDERR ..., then redirect stderr into another file)?
Dr.Ruud
> ` `;
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.
>
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.