in reply to (MeowChow) Re2: When does $_ get used?
in thread When does $_ get used?

My idea, and what I thought elbie's idea was, is treating the @list like a filehandle (i.e. the ever used while (my $line = <STDIN>) { something_with $line }). However, I submit to your [much] greater knowlegde, and vow never to do it myself.

__________________________________________________
<moviequote name="The Whole Nine Yards">
Jimmy T: Oz, we're friends, friends do not engage in sexual congress with each others wives.
</moviequote>

mexnix.perlmonk.org

Replies are listed 'Best First'.
(MeowChow) Re3: When does $_ get used?
by MeowChow (Vicar) on Jul 26, 2001 at 22:54 UTC
    Actually, Perl treats filehandle input within while loops as a special case, to avoid exactly this problem, and to allow for a more natural idiom. To quote the relevant bit of arcana from the POD:
      
    while (my $line = <STDIN>) { print $line }
    In these loop constructs, the assigned value (whether assignment is automatic or explicit) is then tested to see whether it is defined. The defined test avoids problems where line has a string value that would be treated as false by Perl, for example a ``'' or a ``0'' with no trailing newline. If you really mean for such values to terminate the loop, they should be tested for explicitly...

       MeowChow                                   
                   s aamecha.s a..a\u$&owag.print
Re:{2} (MeowChow) Re2: When does $_ get used?
by dragonchild (Archbishop) on Jul 26, 2001 at 23:01 UTC
    while is, in my opinion, generally waaaay over-used. foreach generally does everything you want in a while, and more (like assigning to $_). If you want to treat @list like a filehandle, then do a foreach(@list).

    As a sidenote, you can also do something like:

    foreach (<>) { # Do something with $line here... }
    What that does is require that all the input be done, then release the output. This is unlike while (<>), which will pass its value through to the loop immediately. The difference is because foreach needs to know when it ends, while while doesn't care and will keep going until it's given a false value.
Re: Re: (MeowChow) Re2: When does $_ get used?
by John M. Dlugosz (Monsignor) on Jul 27, 2001 at 11:07 UTC
    Reading from a file doesn't have the "false false" problem on reading a 0 or empty line because the value read includes the trailing "\n" so will never be empty. As for why "0\n" isn't treated as false, I don't know -- normally the trailing stuff in a string is silently ignored, but (experimenting...) it seems that a string that converts to a value of zero is still true if it has stuff after it other than spaces (and maybe other things -- not tested everything, but not \n so not whitespace in general). But it's still zero in an expression, so "0 " is false, "0 pigs" is true, and 0+"0 pigs" is false. It's one of those places where Perl does what you want, most of the time, but is hard to understand if you want complete details.

    —John

      No, at least part of your testing was flawed. "0 ", "0\n", "00", and even "0.0" are all true values. The only false values are "" and "0", period. Boolean context does not first convert the scalar to a number. undef is a special case of "" and numeric 0 is a special case "0" (or at least that is one way to think of it).

      The real false values are "" and numeric 0 but "0" is also considered false because otherwise it would get really confusing. (: But there is no way for a numeric zero to get silently promoted to include a string value like "0 " or "0\n". Numeric zero always becomes simply "0", so we don't need to make any other strings false.

              - tye (but my friends call me "Tye")
        Boolean context does not first convert the scalar to a number

        Ah, I see.

        No, at least part of your testing was flawed. "0 ", "0\n", "00", and even "0.0" are all true values. The only false values are "" and "0", period.

        perl -e "print (0+qq(0 )?'true':'false')" perl -e "print (qq(0\n)?'true':'false')"
        What am I doing wrong? It looks like "0 " is indeed false, while "0\n" is true.

        Update: I didn't notice I still had the 0+ in there. I tried a bunch of variations. That's what I get for experimenting at 2am!

        —John