Problem with <STDIN>

[sivaramanm]

Hi Monks,

I have a problem in <STDIN>. When I use it inside a foreach loop, it doesn't terminate in command prompt for the first iteration.

Thanks

foreach (grep(/^.*\.xml$/, readdir(DIR)))
{
open (FIN, "<$_") or die ("$_ is not opened\n");
undef $/;
print "Pls enter Section level value for $_ :  ";
chop ($seclev = <STDIN>)
}

[borisz]

The problem is about undef $/; delay it until you want to slurp the file

foreach ( grep( /^.*\.xml$/, readdir(DIR) ) ) {
  print "Pls enter Section level value for $_ :  ";
  chop( $seclev = <STDIN> );
  {
    local $/;
    open( FIN, "<$_" ) or die("$_ is not opened\n");
   ..  
}
}

[shmem]

It can't. It doesn't know how to. You did undef $/, so it reads from STDIN forever ;-)

[strat]

Better don't use chop for removing newlines; chop just removes the last char which is ok for unix and linux but not for windows, because there the newline has two chars: CR + LF. Better use chomp which is aware of the different types of line endings

[GrandFather]

The important distinction with chomp is that it removes $/ from the end of each element in the list passed to it (nothing happens if an element is not terminated with $/).

Chop removes the last character without regard to what the character is - chop always alters a non-empty element.

Note in particular that line end differences between file systems have been papered over by this stage and the default value for $/ is \n (which may or may not be a line feed character; you don't need to know). Neither chop nor chomp know or care about file system line end differences.

[ikegami]

No, that's completely wrong. chomp removes what's in $/ from the end of its arguments. $/ is equal to \n (by default) in Windows, so chomp only removes \n (by default) on Windows too.

Read more... Proof (1234 Bytes)

Perl translates CR+LF to LF for you when you read from a file in Windows (unless you use binmode on that handle). Similarly, Perl translates LF to CR+LF when writting to a file handle in Windows (unless you use binmode on that handle).

The reason to use chomp is to handle the case where a line without the line terminator is read in. chop would fail to perform as desired there, but chomp wouldn't. That has nothing to do with CR+LF vs LF.

Update: Added underlined text to clarify my intended message, at GrandFather's recommendation.

[GrandFather]

It's not that chop fails, as it removes the last character regardless of what that character is. You could interpret that to mean that chop "fails to DWIM", but it hasn't failed, just not met the programmer's expectations.