Welcome to Perl, and best of luck.

Sometimes, if you are starting, diving right into the specs can be pretty overwhelming. And the bundled perldocs are geared primarily towards programmers. Working through a good beginner book is a good place to start, sounds like you are working on that. There are also Tutorials here at PM, too. This one does a better job of answering your question about quotes.

Thanks for the pointer, fishbot. I AM a bit unnerved by the volume of information I need to learn, WHILE converting our .bat files to Perl scripts (I'm expected to learn on the run, so to speak). I've been jumping around from books to websites and back to books every time I have a question, so I've surely missed some valuable information, like the real scoop on variable scope.

In summary, you basically never want to use local.

local is widely misunderstood. The best evidence of this is the frequency of statements like "never use local."

It's more accurate and useful to say that local operates on all variables... except lexical (my) variables. It isn't just for localizing values of whatever package globals your program may have, it is essential for the special globals like $_ and @ARGV.
Furthermore — and this useful fact is often missed — it can localize values in variable spaces which are automatically allocated by the interpreter — for example, elements of arrays and hashes.

use Data::Dumper;
use strict;
use warnings;

my %h = ( foo => 1 );

{
local $h{'foo'} = 2;
print Dumper \%h;
}

print Dumper \%h;
[download]

$VAR1 = {
          'foo' => 2
        };
$VAR1 = {
          'foo' => 1
        };
[download]

I would summarize by saying that As different as lexical variables are from package variables, so is local from my.
local is a run-time function, whereas my is a compile-time keyword (with some run-time effects).
local is very useful in its own way. It is by no means a drop-in replacement for my

Well, I said "basically" never. Like all blanket statements, there are exceptions. Perhaps I should have said: Use my by default, use local when you understand why you can't use my in a specific situation. You can create 'stack-like' aggregates with local as you demonstrate, but you need a very good reason.

# some good reasons:

# if you modify a side-effect global like $/, 
# do it in the smallest scope possible:
my $slurped = do { local $/; <$some_Fhand> };

# override an element of a global aggregate in a 
# limited scope:
{
   local $SIG{"ALRM"} = \&some_handler;
   alarm $timeout;
   some_action();
}
[download]

Of course, I agree that understanding the difference is much better than applying a blanket maxim. (Which is why I pointed to an article that does just that.)

Like all blanket statements, there are exceptions.

But these aren't even exceptions. They are simply other first-class cases.

Perhaps I should have said: Use my by default, use local when you understand why you can't use my in a specific situation.

That would certainly be better, but, like your previous post, it begs the usage context. Which is, namely: When you want to declare a variable. local is not good for declaring variables. In fact, it simply does not do that at all! What it does (and this was pretty much your first and only line of defence in Perl 4) is let you safely use a prior existing global variable in your "private" scope. As long as all scopes follow the protocol of localizing their variables before use, global variables can work fine. But that's a big "if", and lexical variables (introduced in Perl 5) allow a great measure of safety which doesn't even depend on every scope abiding by the rules.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.