I am sorry if I am putting you on the defensive. I don't mean to. I just see a number of elementary misunderstandings, and I am trying to help you get beyond them as quickly and painlessly as possible.

As for the three foreach issues, I suspected you didn't know, which is why I explained what Perl is really doing in these three cases.

On the semi-colon issue, I strongly doubt that what I described is wrong for your version of Perl. The following complete program should run fine on any version of Perl you are likely to run across:

print "Hello, World\n" # Note, no semi-colon here!
[download]

The ability to leave off a semicolon only applies to the very last semi-colon in a block. To quote my local copy of perlsyn:

       The only kind of simple statement is an expression
       evaluated for its side effects.  Every simple statement
       must be terminated with a semicolon, unless it is the
       final statement in a block, in which case the semicolon is
       optional.  (A semicolon is still encouraged there if the
       block takes up more than one line, because you may
       eventually add another line.)  Note that there are some
       operators like eval {} and do {} that look like compound
       statements, but aren't (they're just TERMs in an
       expression), and thus need an explicit termination if used
       as the last item in a statement.
[download]

Note that this means that if you drop a random semi-colon, you will get an error. Hence I suspect that you have simply never run into the fact that a small number of semi-colons are optional. But if you run my one-line program above and do get an error, then please follow with the command:

perl -V
[download]

and tell me the results so I know which version of Perl does not behave as I expect.

For your local copy of Perl's built-in documentation (be warned that there is a lot of it, and it is slow going) you can type in:

perldoc perl
[download]

at a command line and work from there. (The perldoc utility comes with Perl itself and has run just fine for me on all versions of Windows where I have tried it.)

And finally about the open issue. For testing your fix you can change the command to something that will run on your machine. But it is pretty much always a bad programming idea to interact with the system without having an error check. Sure, on your machine the program doesn't exist. But even if you are running on Linux and know full well that the line should work, the error check still belongs. There are always things that can go wrong, and that is a place where they tend to. Without that check you won't be able to easily identify and debug any of the following errors:

1. You have a typo in your name of the command.
2. You moved your script from one machine to another and the other does not have the command you expect, where you expect it.
3. Your script is running in a chrooted environment and the command is not available at all to you.
4. Your machine has run out of memory/processes/etc and is unable to run the command at all.
5. etc...

For these reasons and more, consistently putting in good error checks is listed in perlstyle as a more substantive style issue. (For the record, I learned how substantive when I had to get a job that took 30 minutes to run to run cleanly when it was dying without a useful error check about 20 minutes into the run. Turns out that someone with root had left the wrong permission on one file in a directory of thousands. When I left work at 1 AM I was not a happy camper...)