You can store the matches in an array:

$_ = 'abcd';
if (my @matches = /(.)(.)/) {
    for my $i (0, 1) {
        print "$i: $matches[$i]\n";
    }
}
[download]

perl -e "$ARGV[0] =~ /(a)(l)(l)/;  print qq($1 $2 $3) " alltogether
#out:a l l

perl -e "@array = $ARGV[0] =~ /(a)(l)(l)/;  print qq(@array) " alltoge
+ther
#out:a l l
[download]

Jumping first to your question about the existance of a $wizardextract -- well, yes there is: namely, use of elements enclosed by simple parentheses (eg  /(foo) bar (bat)/ inside the regex (more on this below)

perl -e "my $str='foo bar bat'; if ($str =~ /(foo) bar (bat)/ ) {print
+ \"\$1: $1; \$2: $2)\"; }"
$1: foo; $2: bat)
[download]

Note 1: 'Doze quoting
Note 2: Other uses of parens exist but are outside the scope of your question.

The parens INSIDE the regex -- that is, between the forward slashes -- tell Perl to capture the elements they enclose (when matched) to the special $n variables. The only parens I found in the first half dozen pages of the text you referenced (TL, DRIA) are those required in the if (...) clause which may be a source of your misunderstanding.

Switching topics: you object to the author invoking chomp before introducing it. That's perhaps pedagologicly sound, but it also misses (missed?) a critical lesson about learning Perl!

You can use your command line and Perl's own documententation to understand (or at least get an introduction to) Perl functions. Here's an example:

perldoc -f chomp
    chomp VARIABLE
    chomp( LIST )
    chomp   This safer version of "chop" removes any trailing string t
+hat
            corresponds to the current value of $/ (also known as
            $INPUT_RECORD_SEPARATOR in the "English" module). It retur
+ns the
            total number of characters removed from all its arguments.
+ It's
            often used to remove the newline from the end of an input 
+record
             ....
[download]

HTH

Update: fixed last closing code tag's missing < before the slash-c. TY, many times over, to choroba & hippo

Thank you for your response, ww. The book in chapter 5 in fact covers how to write the regular expression to search data with grouping, and later  print it. I realize now how vague I was being in the question and have changed it to reflect that the regular expression will not be hardcoded, but be <STDIN>

Switching topics: you object to the author invoking chomp before introducing it. That's perhaps pedagologicly sound, but it also misses (missed?) a critical lesson about learning Perl!

To be specific he requests, in chapter 3 that you

3. Store your important phone numbers in a hash. Write a program to look up numbers by the person's name.

I assumed values from <STDIN> would just match, and up till that point chomp isn't mentioned nor is the fact that the <STDIN> function throws in a /n at the end of every entry. I was bashing my head against the wall when the hash wasn't matching the entry, even if (so far as I could tell) it matched verbatim. It was only after pouring over the nodes here for awhile that I discovered the chomp function and what it did.

That being said, I'm sort of glad it happened. It forced me to reach out and do some (?=) as you mentioned.

Personally, I haven't encountered a situation where I needed them, but perlvar also shows @+ and @-, which contain the start and end positions of the captured patterns in the target string. You can iterate over 0..@- to enumerate them all.

for my $i (0..@-) {
    print "$i: $matches[$i]\n";
}
...
Use of unitialized value in concatenation ...
...
... I'm confused as to what the error message means and how to deal with it.

If a regex matches against a string, the zeroth index of the  @- array always holds the overall match offset in the string, and higher indices (1, 2, ...) hold capture group match offsets, if there are any capture groups. (Note that if there is an overall match, all capture groups will be represented in  @- even if they did not match!) See  @- in perlvar. So in a regex that has two capture group matches, there are three elements in the array, and you want to iterate over the range  0 .. $#- to see all match offsets (or maybe over  1 .. $#- to see just capture group match offsets). Iterating over  0 .. @- gives you an extraneous, undefined element beyond the end of the  @- array. (Evaluating an array in scalar context yields the number of elements of the array, not the highest array index, given by $#array.)

I find regular expressions in general to be the least intuitive, most surprising computer "language" I've encountered (technically, they're a Domain-Specific Embedded Language, a DSEL) that is actually intended to be practical and useful rather than merely obscure; for an example of the latter, see Brainfuck, the source code of which looks remarkably like a traditional "line noise" regex definition.

My favorite example of this counter-intuitiveness is the result of matching the simple regex  /(b*)/ against the string  'aaaaabbb':
    'aaaaabbb' =~ /(b*)/;
What will be matched and captured to  $1 and where will the match occur? Knowing that matching is, by default, "greedy" and matches as much as possible, one's first thought might be as mine has often been, that it will match/capture  'bbb' at offset 5 in the string. Contemplation of the "Leftmost, Longest" rule for regex matching would seem to support this initial idea: offset 5 is the leftmost position at which the most  'b' characters are found — all of them in fact.

A simple experiment shows we are deceived:

c:\@Work\Perl\monks>perl -wMstrict -le
"print qq{matched '$1' at offset $-[1]} if 'aaaaabbb' =~ /(b*)/;
"
matched '' at offset 0
[download]

I do not show you these things in order to discourage you, but rather to steel you against the frustrations and perplexities that inevitably accompany the study and use of regular expressions.

Earlier in the chapter it notes that when using a Regular Expression with grouping, the sucker "eats up" hits and stores them in incrementally changing variables of $1, $2...