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!
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.
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
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
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:
- You have a typo in your name of the command.
- You moved your script from one machine to another and
the other does not have the command you expect, where
you expect it.
- Your script is running in a chrooted environment and
the command is not available at all to you.
- Your machine has run out of memory/processes/etc and
is unable to run the command at all.
- 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...) |