I was able to write this little program which basically
just does one thing. It will record which server I have to work on(no
I can't do this w/ cron. as it has to be done manually and also i am
trying to learn perl here).
#!/usr/bin/perl -w
open(FH, "+<server_watch") || die ;
$count = <FH>;
if ($count == 1) {$count=2 ;}
else {$count=1;}
seek(FH, 0,0) || die;
print FH "$count";
close(FH);
That's not bad at all, my only criticisms are quite minor because is a
"quick ('n' dirty)" program. There are a number of techniques used in
your code that are great in a "quick 'n' dirty" program such as this
but would be bad in a real one. Since you say you want to learn Perl
I'll point them out.
Even in a quick program you should incude the error in your error
messages!
open(FH, "+<server_watch") || die $!;
In serious programs you'd probably want to include more information:
open(FH, "+<server_watch") || die "Error opening server_watch: $!";
Note, since this is a quick program I'd have not bothered with the
explicit close().
In your program you use implicitly declared global variables. For
programs below a certain size this can be a saving. For larger
programs in becomes a pain. People disagree about where the line at
which it becomes a pain is drawn but most would agree that by the time
you get to 100 lines and half a dozen subroutines you are well past
it. I, personally, am a very inaccurate typist so I draw the line at
~10 lines.
However, if you are writing small programs not as quick programs in
their own right but as a exercises in learning how to write real
programs you should get into the habit of putting "use strict;" at the
top of even your shortest programs and always declaring all variables
as lexically scoped (using my) in the smallest applicable scope
(unless there's a reson to do otherwise).
In the case of your program there's only one variable so:
$count = <FH>;
Would become
my $count = <FH>;
Putting "use strict" will disable the implicit global variable
declaration, it also disables two other features that you will rarely
need and you really don't want enabled until you've understood what
they do. (For details RTFM).
Bare filehandles, IMHO, are also a feature that's best restricted to
"quick" programs.
In larger programs you are better off using a lexical variable.
open(my $FH, "+<server_watch") || die "Error opening server_watch:
$!";
IMNSHO, the 2-arg open() in which the mode and file paramters are
concatenated is largely a legacy feature. If you are just starting
Perl now you may as well go straight to the newer syntax.
open(my $FH,'+<','server_watch') || die "Error opening server_watch:
$!";
In larger programs you should always use the more flexible "use
warnings" rather than the "-w" switch. In "quick" programs where the
few keystokes is significant then use the -w by all means.
In real (as opposed to Q&D) programs you should import the SEEK_SET
constant from the Fcntl module rather than assume it is 0. That said
I don't think there are any platforms on which Perl is ever likely to
be implemented on which it is anything else!
Oh and you may also wish to see FAQ: What's wrong with always quoting
"$vars"?
Also, if anyone knows that there are already written little scripts
like this.
The point about Q&D programs is you write them quickly to do one
thing, there would be no point publishing them.
Perhaps you should be looking at early examples in a Perl tutorial.
Be aware that there are many bad tutorials out there. Most (but not
all) of the bad ones can be spotted by the following features:
They don't "use strict" and "use warnings".
They either don't declare variables using my() or
don't do so in the smallest applicable scope.
They use & on all subroutine calls.
I like to look at other people's codes...... to learn.
If you really want to look at other people's first attempts you should
consider looking in some of the Perl newsgroups that exist in this
hierachy (as opposed to this one that does not). That way you not
only see the code but also the critique. Just looking at other
people's first attempt would be a case of people who don't know what
they are doing pooling their ignorance. Of course, if you really want
to pool ignorance about Perl there's a newsgroup specially for that
too: alt.perl!
