"'local' temporarily changes the value of the variable, but only within the scope it exists in."

Here's a nice way to distinguish my from local.

• my works in space: the program sees that variable (by that name) throughout the static scope. That scope is simply delimited from the point of the `my' to the end of the block. If I say

  {
    # ...
    my ($x, @y, %z);       # (1)
    # ...
    sub foo { # ...
    }
    # ...
    foo(17);               # (2)
    bar($x,29);            # (3)
    # ...
  }                        # (4)
  # ...
  sub bar { # ...
  }
  [download]

  then %z,@y,$x are the temporary ones from declaration (point (1)) to the end of the block (point (4)). In particular, the call to foo (point (2)) can see all three variables, because foo was defined within the scope. The call to bar (point (3)) can't see @y,%z, because bar is defined outside the block's scope. Of course, that particular call can see $x as a parameter.

  Note how easy it is to tell the scope of a `my' declaration: it's a lexical thing. All you have to do is look for the end of the block (point (4)). The `my' variable is visible from its declaration to the end of the block, and nowhere else.

• local works in time: the program sees that version of the (global) variable in the dynamic "scope". The version of the variable is used from the moment (at run time) where the `local' declaration is encountered, to the moment (again at run time) where the block ends. It doesn't matter where your code is defined, it gets to see that version of the variable if it gets to run between these two times. That's why `local' variables are versions of global variables: they potentially have to be seen by all routines in the program. If I say

  use vars qw/$x, @y, %z/;
  {
    # ...
    local ($x, @y, %z);     # (5)
    # ...
    sub baz { # ...
    }
    # ...
    baz(17);                # (6)
    quux($x,29);            # (7)
    # ...
  }                         # (8)
  # ...
  sub quux { # ...
  }
  # ...
  baz(29);                  # (9)
  [download]

  then the global variables $x,@y,%z (declared in the use vars pragma) are given temporary versions at point (5). These temporary versions are in effect until execution reaches the end of the block (point (8)), at which time the old versions come back.

  It doesn't matter that baz is defined inside the block. The call at point (6) uses the temporary versions, because it happens (in time!) between (5) and (8); the call at point (9) uses the original versions, because it happens (in time!) after (8). The call to quux can see the temporary versions of all 3 variables, even though the definition of quux occurs outside the variable. What matters is that the call occurs during the temporary scope.