Still Trying to Understand Perl Module Control Process

2014-01-14 Thread Martin G. McCormick
I am using cpanp or cpan plus to handle perl modules on
a FreeBSD system. If I give the command

cpanp -i Net::DNS
it installs Net::DNS 0.73. Normally, this is exactly what one
would want it to do but Net::DNS0.73 is buggy. At least one bug
causes domain name server or DNS updates to fail so I either
want the version just below Net:DNS0.73 or there are a couple of
versions of it dated January of 2014, basically anything but the
one it keeps trying to install.

What am I supposed to do to safely fix this problem and
hopefully keep the rest of perl working and cause the
installation of Net::DNS 0.something else?

cpanp -h says, in part,

i MODULE | NUMBER ...  # install module(s), by name or by search number

cpanp -f Net::DNS lists all versions of Net::DNS and
their release dates of which there are 11. What is the search
number?

Thank you.

Martin

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Still Trying to Understand Perl Module Control Process

2014-01-14 Thread David Precious
On Mon, 13 Jan 2014 10:32:14 -0600
Martin G. McCormick mar...@server1.shellworld.net wrote:

   I am using cpanp or cpan plus to handle perl modules on
 a FreeBSD system. If I give the command
 
 cpanp -i Net::DNS
 it installs Net::DNS 0.73. Normally, this is exactly what one
 would want it to do but Net::DNS0.73 is buggy. At least one bug
 causes domain name server or DNS updates to fail so I either
 want the version just below Net:DNS0.73 or there are a couple of
 versions of it dated January of 2014, basically anything but the
 one it keeps trying to install.

You can provide the exact one you want, e.g.:

cpanp -i NLNETLABS/Net-DNS-0.72.tar.gz


(I don't use cpanplus, but I'd imagine that'll work; it does with cpan
and cpanm)



-- 
David Precious (bigpresh) dav...@preshweb.co.uk
http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter
www.preshweb.co.uk/linkedinwww.preshweb.co.uk/facebook
www.preshweb.co.uk/cpanwww.preshweb.co.uk/github



-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Package version numbers

2014-01-14 Thread SSC_perl
I'm trying to number packages the way it's written about on page 406 of 
Programming Perl, 4th ed., e.g. 

package Emailer 1.01;

However, when I do that, I get the following error:

syntax error at ss_files/Emailer.pm line 1, near package Emailer 1.01
Compilation failed in require at admin.cgi line 38.
BEGIN failed--compilation aborted at admin.cgi line 38.

I'm running Perl 5.10.1 on my laptop so that should be new enough to 
handle this.  What am I doing wrong?

Thanks,
Frank

http://www.surfshopcart.com/
Setting up shop has never been easier!


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Package version numbers

2014-01-14 Thread John SJ Anderson
On Tue, Jan 14, 2014 at 2:50 PM, SSC_perl p...@surfshopcart.com wrote:
 I'm trying to number packages the way it's written about on page 406 
 of Programming Perl, 4th ed., e.g.

 package Emailer 1.01;

 However, when I do that, I get the following error:

 syntax error at ss_files/Emailer.pm line 1, near package Emailer 1.01
 Compilation failed in require at admin.cgi line 38.
 BEGIN failed--compilation aborted at admin.cgi line 38.

 I'm running Perl 5.10.1 on my laptop so that should be new enough to 
 handle this.  What am I doing wrong?

I'm not sure exactly when that syntax was added, but for what it's
worth, it fails with 5.10.1 here too. Perl 5.12.5, on the other hand,
works.

You may just need to upgrade.

chrs,
john.

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Package version numbers

2014-01-14 Thread SSC_perl
On Jan 14, 2014, at 4:04 PM, John SJ Anderson wrote:
 I'm not sure exactly when that syntax was added, but for what it's
 worth, it fails with 5.10.1 here too. Perl 5.12.5, on the other hand,
 works.
 
 You may just need to upgrade.

Thanks for the test, John.  In the book's example, they have:

use v5.10;

so I thought I was new enough, but maybe not.

I've resorted to adding:

use vars '$VERSION'; $VERSION = '1.01';

after the package declaration.  That works, but it's just not as clean looking. 
 Not a big deal, though.

Thanks again,
Frank

http://www.surfshopcart.com/
Setting up shop has never been easier!


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Package version numbers

2014-01-14 Thread John SJ Anderson
 Thanks for the test, John.  In the book's example, they have:

 use v5.10;

 so I thought I was new enough, but maybe not.

http://use.perl.org/use.perl.org/articles/10/04/13/1953252.shtml also
notes it as a new feature in 5.12. I'm sure the authors regret the
typo. ;^)



j.

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Identifying the current opened filehandle for writing as I'm getting undefined variable concatenation errors

2014-01-14 Thread Matt McAdory
Is there a method for determining the currently selected filehandle? should
I always check for undef and open my filehandle before writing to it?

use strict;
use warnings;
use autodie qw (:all);

use My:CustomMod_with_FH_write;

open (my $FH, , filename.txt);

my $var = My:CustomMod_with_FH_write-new;
my @array = $var-sub1(); #writes to it's FH, but returns me an array of
stuff
print $FH, some stuff\n; # works great.
while (@array) {
chomp;
my @array2 = $var-sub2($_);  #gets some new stuff in another array,
prints again to the module FH
while (@array2) {
chomp;
my $thing = $var-sub3($_); # returns a scalar
print $FH $thing\n;
# BOOM!?!?
}
}




the last print always give me a . . . . concatenate (.) to undefined
variable $FH near line . . . . and I can't understand where I'm scoping
out and my $FH gets closed. Add the open below and it works. Granted this
is some dummy code, I'm not in the office right now to give specifics, but
sub calls to the module work fine. Write to the my filehandle works fine .
. . until I get to a certain level of nesting and then it bombs and I don't
understand why nor can I find a way to print the active filehandle. What am
I doing wrong? The module FH and my FH are different files in different
directories. I probably need to find a different way of doing what I'm
doing.

Should that BOOM always be:

if (undef $FH) {open (my $FH, , filename.txt);}
print $FH $thing\n;
close $FH;

A friendly page in the fine manual to read. A nudge towards a llama or
camel reference would be appreciated. Several days show my googlefu to be
lacking. Where is my rookie mistake?

Matt


Re: Identifying the current opened filehandle for writing as I'm getting undefined variable concatenation errors

2014-01-14 Thread Brian Fraser
On Wed, Jan 15, 2014 at 12:09 AM, Matt McAdory m...@mcadory.info wrote:

 Is there a method for determining the currently selected filehandle?
 should I always check for undef and open my filehandle before writing to it?

 use strict;
 use warnings;
 use autodie qw (:all);

 use My:CustomMod_with_FH_write;

 open (my $FH, , filename.txt);

 my $var = My:CustomMod_with_FH_write-new;
 my @array = $var-sub1(); #writes to it's FH, but returns me an array of
 stuff
 print $FH, some stuff\n; # works great.


You mention that this is some dummy code, but for what it's worth, you got
an extra comma there.


 while (@array) {
 chomp;
 my @array2 = $var-sub2($_);  #gets some new stuff in another array,
 prints again to the module FH
 while (@array2) {
 chomp;
 my $thing = $var-sub3($_); # returns a scalar
 print $FH $thing\n;
 # BOOM!?!?
 }
 }


 

 the last print always give me a . . . . concatenate (.) to undefined
 variable $FH near line . . . . and I can't understand where I'm scoping
 out and my $FH gets closed.

Add the open below and it works. Granted this is some dummy code, I'm not
 in the office right now to give specifics, but sub calls to the module work
 fine. Write to the my filehandle works fine . . . until I get to a certain
 level of nesting and then it bombs and I don't understand why nor can I
 find a way to print the active filehandle. What am I doing wrong? The
 module FH and my FH are different files in different directories. I
 probably need to find a different way of doing what I'm doing.

 Should that BOOM always be:

 if (undef $FH) {open (my $FH, , filename.txt);}
 print $FH $thing\n;
 close $FH;

 A friendly page in the fine manual to read. A nudge towards a llama or
 camel reference would be appreciated. Several days show my googlefu to be
 lacking. Where is my rookie mistake?

 Matt


You'll have to post some code that actually reproduces the issue. Keep in
mind that the 'my $FH' is a lexically scoped filehandle, so unless you're
actually passing it to the module that uses it, or using select($FH) to
change the default filehandle, there's no way that the module in question
will be able to use the filehandle in $FH.


Re: Identifying the current opened filehandle for writing as I'm getting undefined variable concatenation errors

2014-01-14 Thread Rob Dixon

On 15/01/2014 03:09, Matt McAdory wrote:

Is there a method for determining the currently selected filehandle?
should I always check for undef and open my filehandle before writing to it?

use strict;
use warnings;
use autodie qw (:all);

use My:CustomMod_with_FH_write;

open (my $FH, , filename.txt);

my $var = My:CustomMod_with_FH_write-new;
my @array = $var-sub1(); #writes to it's FH, but returns me an array of stuff
print $FH, some stuff\n; # works great.
while (@array) {
 chomp;
 my @array2 = $var-sub2($_);  #gets some new stuff in another array, 
prints again to the module FH
 while (@array2) {
 chomp;
 my $thing = $var-sub3($_); # returns a scalar
 print $FH $thing\n; 
# BOOM!?!?
 }
}




the last print always give me a . . . . concatenate (.) to undefined
variable $FH near line . . . . and I can't understand where I'm scoping
out and my $FH gets closed. Add the open below and it works. Granted
this is some dummy code, I'm not in the office right now to give
specifics, but sub calls to the module work fine. Write to the my
filehandle works fine . . . until I get to a certain level of nesting
and then it bombs and I don't understand why nor can I find a way to
print the active filehandle. What am I doing wrong? The module FH and my
FH are different files in different directories. I probably need to find
a different way of doing what I'm doing.

Should that BOOM always be:

if (undef $FH) {open (my $FH, , filename.txt);}
print $FH $thing\n;
close $FH;

A friendly page in the fine manual to read. A nudge towards a llama or
camel reference would be appreciated. Several days show my googlefu to
be lacking. Where is my rookie mistake?


In this case the currently-selected file handle is irrelevant as all
your print statements specify the file handle explicitly.

Your problem isn't with a closed file handle, which would report

print() on closed filehandle

but with the contents of $thing. The statement

print $FH $thing\n

will report

Use of uninitialized value $thing in concatenation (.) or string

if $thing is undefined.

Rob

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Identifying the current opened filehandle for writing as I'm getting undefined variable concatenation errors

2014-01-14 Thread Matt McAdory
The comma was a pseudo code error. Should have read
=
print $FH some stuff\n; # works great.
=

I will test for undef on $thing. Thanks for looking. Pretty sure I printed
the expected result to STDOUT without error. The module call involves a
telnet across the network, maybe the open I added provides enough time for
$thing return some data. I will experiment with sleep(5). I would use
expect for the telnet session, but this has to be run by activeperl on a
windows platform. :/ I'd use the alternative for expect if I had the
choice. Thanks again for looking.




Matt


On Tue, Jan 14, 2014 at 9:37 PM, Rob Dixon rob.di...@gmx.com wrote:

 On 15/01/2014 03:09, Matt McAdory wrote:

 Is there a method for determining the currently selected filehandle?
 should I always check for undef and open my filehandle before writing to
 it?

 use strict;
 use warnings;
 use autodie qw (:all);

 use My:CustomMod_with_FH_write;

 open (my $FH, , filename.txt);

 my $var = My:CustomMod_with_FH_write-new;
 my @array = $var-sub1(); #writes to it's FH, but returns me an array of
 stuff
 print $FH, some stuff\n; # works great.
 while (@array) {
  chomp;
  my @array2 = $var-sub2($_);  #gets some new stuff in another array,
 prints again to the module FH
  while (@array2) {
  chomp;
  my $thing = $var-sub3($_); # returns a scalar
  print $FH $thing\n; 
 #
 BOOM!?!?
  }
 }


 

 the last print always give me a . . . . concatenate (.) to undefined
 variable $FH near line . . . . and I can't understand where I'm scoping
 out and my $FH gets closed. Add the open below and it works. Granted
 this is some dummy code, I'm not in the office right now to give
 specifics, but sub calls to the module work fine. Write to the my
 filehandle works fine . . . until I get to a certain level of nesting
 and then it bombs and I don't understand why nor can I find a way to
 print the active filehandle. What am I doing wrong? The module FH and my
 FH are different files in different directories. I probably need to find
 a different way of doing what I'm doing.

 Should that BOOM always be:

 if (undef $FH) {open (my $FH, , filename.txt);}
 print $FH $thing\n;
 close $FH;

 A friendly page in the fine manual to read. A nudge towards a llama or
 camel reference would be appreciated. Several days show my googlefu to
 be lacking. Where is my rookie mistake?


 In this case the currently-selected file handle is irrelevant as all
 your print statements specify the file handle explicitly.

 Your problem isn't with a closed file handle, which would report

 print() on closed filehandle

 but with the contents of $thing. The statement

 print $FH $thing\n

 will report

 Use of uninitialized value $thing in concatenation (.) or string

 if $thing is undefined.

 Rob

 ---
 This email is free from viruses and malware because avast! Antivirus
 protection is active.
 http://www.avast.com