Question from the perlmod man pages.

[grocery_stocker]

I'm sort of drawing a stump on the following:

"Perl packages may be nested inside other package names, so we can have
package names containing ::. But if we used that package name directly
as a filename it would make for unwieldy or impossible filenames on
some systems. Therefore, if a module's name is, say, Text::Soundex,
then its definition is actually found in the library file
Text/Soundex.pm."

Say I have a module name Text::Soundex. I use this in my Perl script
as:

use Text::Soundex;

I know there is a module called Soundex.pm. I also know there is a
directory
name with the name Text. However, would there also be a module named
Text.pm?

Chad

 

[Jim Gibson]

I'm sort of drawing a stump on the following:

"Perl packages may be nested inside other package names, so we can have
package names containing ::. But if we used that package name directly
as a filename it would make for unwieldy or impossible filenames on
some systems. Therefore, if a module's name is, say, Text::Soundex,
then its definition is actually found in the library file
Text/Soundex.pm."

Say I have a module name Text::Soundex. I use this in my Perl script
as:

use Text::Soundex;

I know there is a module called Soundex.pm. I also know there is a
directory
name with the name Text. However, would there also be a module named
Text.pm?

No, there need not be a module named Text.pm. The pattern A::B is a
naming convention, and does not establish a hierarchical relationship
between modules A and B or their symbol tables. See 'perldoc perlmod'
for details.

 

[grocery_stocker]

No, there need not be a module named Text.pm. The pattern A::B is a
naming convention, and does not establish a hierarchical relationship
between modules A and B or their symbol tables. See 'perldoc perlmod'
for details.

The source of this confusion stems from the following lines of code:

#!/usr/bin/perl

# change these two lines
$server_port = 1234;
$identification_phrase = 'insert phrase here';

# redirect error messages to a logfile
open(STDERR, ">>/tmp/logserver.log");

# code stolen liberally from Perl Cookbook

use IO::Socket;

$logfile = $ARGV[0];
open(LOG, "<$logfile");
# read to the current end of the log
while(<LOG>) {
}

$server = IO::Socket::INET->new(LocalPort => $server_port,
Type => SOCK_STREAM,
Reuse => 1,
Listen => 10 ) # or SOMAXCONN
or exit; # "Couldn't be a tcp server on port $server_port : $@\n";

while (($client,$client_address) = $server->accept()) {
($client_port, $client_ip) = unpack_sockaddr_in($client_address);
@decimal_address = unpack("C4", $client_ip);
$ip_number = join(".", @decimal_address);
warn "connection from $ip_number";
while(<$client>) {
last if /$identification_phrase/;
}
warn "connection from $ip_number gave pass phrase";
$lines = 0;
while(<LOG>) {
$lines++;
print $client $_;
}
warn "returned $lines lines to $ip_number";
close($client);
}

close($server);

Why go

use IO::Socket;

Why just not

use IO::Socket::INET;

in this case

 

[xhoster]

The source of this confusion stems from the following lines of code:

#!/usr/bin/perl

# change these two lines
$server_port = 1234;
$identification_phrase = 'insert phrase here';

# redirect error messages to a logfile
open(STDERR, ">>/tmp/logserver.log");

# code stolen liberally from Perl Cookbook

use IO::Socket;
....

$server = IO::Socket::INET->new(LocalPort => $server_port, ....


Why go

use IO::Socket;

Why just not

use IO::Socket::INET;

in this case

No particular reason that I can think of. When you use IO::Socket, it
automatically uses IO::Socket::INET for you. That is just the kind of
relationship that IO::Socket and IO::Socket::INET have with each other.
Other modules have a more stand-offish relationship.


OK, maybe one reason to use IO::Socket rather than IO::Socket::INET is
that, if you decide to switch to the different kind of socket, (say, UNIX)
then you would only need to change the "new" line rather than changing both
the "new" and the "use".

Xho