Hi fireblood,

... the inner "for" would replace that list with a list of its own

This is the bit of logic that choroba already pointed out is the mistake: the outer for sets a local $_ to each of the lines of input, while the inner for sets a local $_ to each return value of the split (which is only called once on each iteration of the outer loop, and it splits the outer loop's $_, i.e. the line).

See Foreach Loops (emphasis mine):

The foreach loop iterates over a normal list value and sets the scalar variable VAR to be each element of the list in turn. If the variable is preceded with the keyword my, then it is lexically scoped, and is therefore visible only within the loop. Otherwise, the variable is implicitly local to the loop and regains its former value upon exiting the loop. If the variable was previously declared with my, it uses that variable instead of the global one, but it's still localized to the loop. This implicit localization occurs only in a foreach loop. ... If VAR is omitted, $_ is set to each value.

I acutally wanted to pick up on something else:

Before I start relying on this behavior in production programs

I would be very careful with nested loops setting multiple versions of $_ in production programs. It's incredibly easy to introduce a bug by just moving a line around. My view on this is not as strict as some other peoples' that I have seen, who say to avoid $_ as much as possible and use named lexicals everywhere. I think that for short loops of maybe 1-3 lines of code, using $_ is usually fine. However, nested loops usually exceed that limit and so in the example you've posted, I'd recommend you use named lexicals in both your loops.

Hope this helps,
-- Hauke D

But even moving the print "Current line is $_"; after the inner "for" still works, i.e. the whole line is printed, not just its last entry. That's because the "foreach" loop localizes its loop variable (see Foreach Loops).

BTW, one usually uses the diamond operator with while rather than for .

Update: See $_ getting clobbered by inner loop. for an example where the problem really happens.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Regardless of how $_ behaves, not using explicit named loop variables is bad coding practice. Well named variables document your code and make it easier to understand, both by you now as you write and debug the code, and by a future stranger with no idea of how the code works (likely a future you) who has to maintain the code.

Do the smart thing, use named variables. You'll thank yourself for it in the future.

Whilst I would generally agree, there's a few places where I consider using $_ to be reasonable. They're mostly the places where I'm not using it explicitly.

So something like:

     while ( <$input> ) { 
         chomp; 
         my @row = split;
         #stuff
     }
[download]

I think is fine, because you _are_ naming it - but still using $_ to preprocess. Likewise sometimes a for loop of the form:

     $_ -> methodcall() for @objects;
[download]

I'm increasingly starting to appreciate it - and as a rule of thumb, if I'm actually _writing_ $_ outside of a single line command (e.g. map/grep/for) then I should be using a named variable.