On Mon, Oct 17, 2011 at 2:05 PM, sunckell <sunck...@gmail.com> wrote:
> So here we are back to the script.. The script works as
> expected, with one item of strangeness. I was expecting the
> log messages to be printed in the order they complete. For
> example, if the connection attempt at 12:01 took 75 seconds to
> return, and the connection attempt at 12:02 to 5 seconds to
> return, I would expect the 12:02 message to appear first then
> the 12:01, but it doesn't. The 12:02 connection won't print
> until the 12:01 returns.
> use strict;
You probably want the 'warnings' pragma too. :)
> $|++;
Well I'm out of ideas. :P
> if ($pid) {
> # parent
> } elsif ($pid == 0) {
> # child
> my $p = _initialize($ct);
> waitpid($p, 0);
> exit 0;
> } else {
> die "couldnt fork: $!\n";
> }
nitpick:
I would much rather see that as something like this:
die "couldn't fork: $!" unless defined $pid;
if($pid == 0)
{
my $p = _initialize($ct);
waitpid($p, 0);
exit 0;
}
Irrespective of what it's doing, it drives me nuts to see an
if...else ladder (or any control structure) with an empty block.
:P I have a colleague that does it and it drives me crazy.
It also makes sense to me that if you're going to die when
something fails that you probably want the die as close to the
thing failing as possible to make it clear.
/nitpick
> my $user = 'root';
That looks a bit dangerous to me, but I digress. :P If it were me
I'd probably prefer to use a non-root user for anything
involving an automated SSH session. I'll trust that you know what
you're doing then.
> sub write_to_log{
> my ($message) = @_;
>
> my $log = "/tmp/$short_name.log";
>
> if ($debug){
> print "$message\n";
> }
>
> open L, ">>$log" or die "Cannot open $log:$!\n";
> print L "$message\n";
> close L;
> }
Are you sure it's necessary to open and close the log file every
time you write to it? That doesn't look particular good to me.
Couldn't you just open it one time in the parent process? Perhaps
that accounts for the variance in write order.
/guess
> Just wondering why the messages being printed to the console
> waits for the previous pid (or pids) to complete before it's
> viewable.
I don't think you can rely on the order of things happening
though in different processes (or threads). So I don't know that
it's really anything to be concerned about. If anything, I would
design the output so that order didn't matter. As you said, you
can always sort the output later if it helps to interpret it. I'm
only assuming that I understand what's happening though. ^_^
--
Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bamccaig.com/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
