1. A class for an OO system
2. A repository of functions, with Exporter

You would download a module from CPAN and install it, using the instructions that came with the module.

As for more info, I suggest purchasing Programming Perl, 3rd edition. There's a number of chapters there about modules and a whole chapter on CPAN.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I think the first thing you need to learn is how to use the documentation that comes with Perl: try the following:

Which leads you to:

Which should lead you to:

and to:

Note that man perl would also lead you to this information and that on Windows Active Perl also comes with the doc.

Of course you can also use the Search on this site, but this should get you started!

George,

I agree with you, but I also think it is important for a newbie not to rely too much on modules because even though it will take more time to write your own code, I feel you learn Perl faster this way. This was the case when I started out. People were suggesting modules left and right and I said to myself "How am I going to learn this stuff if all I'm doing is using other people's code?"

Now that I have a better grasp on Perl, I find myself using CPAN much more. I would suggest to a newbie to try and write the code themselves first and then check out CPAN to see if a module can do something they want better/faster (which is usually the case).

Hope I don't get flamed for this, but this is the approach that I took.

-Dru

No flames, so long as you know you're wrong ;-) just kidding. Seriously though it's dependent on the end user. If they are the curious type and will actually attempt to understand the modules they use then that's good. I just rewrote a script from years ago that I used to select 5 random lines from a file that was atrocious, no scoping, vast assumptions (one of which was causing it to get locked in an infinite loop! Very Bad since it was run by cron), etc. etc. So I got Algorithm::Numerical::Shuffle and the script is now much more stable and trivial. And I really think that it would have been best for me to have used it in the first place long long ago. I would have been more confident in the script (or justifiably so), and spent time on making it work well instead of just making it work. On the other hand I wouldn't have been able to (it would have unnecessary) revisit it and see how very far I'd come ;-).

--
perl -p -e "s/(?:\w);([st])/'\$1/mg"

It's a balance, really, IMHO. One needs to have an idea how the modules work otherwise one can't use them intelligently. But at the same time one has to let them do the work otherwise there's no point. But my guess is that most beginners err on the side of *not* using modules, and will always find ways to practice their skills by re-inventing a whole load of wheels. I too learnt a fair amount by rolling my own, but I think I would have learnt other things quicker, and been more productive, if I'd made the jump to modules sooner.

Also, a fab way to learn good programming style is to look at how the modules do it. So instead of learning by rolling one's own, one can learn by getting to grips with the real thing.

§ George Sherston

Let's take things ong at a time, eh? I think you're going to want explainations in basic terms, and that's what I'm good at -- writing things in painfully terse form :)

* What is a module? - A module is basically a collection of subrouties that is not a program by itself, but is used by other programs. It's all about code recuse and astetics. The calling program accesses and uses the subrouting inside the module.

* How do i use it - You just said it: use module_name; or require module_name; Use and Require are similar but have different nuances, so 'use' would be your best bet. Put 'em up near the begining of the program.

* What is CPAN? - CPAN: A networked storage system of Perl Modules. It combines the Storage of the modules, managment and instalation into come seamless package. When people say 'use CPAN', they usually mean do (as root usually) "perl -MCPAN -e shell", which gets you into the CPAN shell where you can install perl modules with a few keystrokes. You want to install NET::IRC? Just type 'install NET::IRC'. It's very slick.

Module != CPAN. You can write you own modules in your own code, and I recommend that you do. CPAN is just a repostory of Generic and useful modules other people have written.

* how does it tie into a module - If you write a module that is usful enough that others would like it, you can bundle it up and put it on the CPAN network for other people to use.

* is their someplace here that can teach me all about modules and using them? - Here would be a great place to start. Using modules is pretty easy, you've probably already seen it/done it and not even known it. Making modules is harder, but worth learning if you want to write high-quality code.

Scott

Now I am going to suppose that you have a place somewhere to put your library of Perl stuff you are developing. For the sake of argument that will be "/your/library/path". Now let's create the Foo::Bar module. Create the file "/your/library/path/Foo/Bar.pm". Into it put this:

package Foo::Bar;
use Exporter;
@ISA = 'Exporter';
# This is a list of functions you are willing to export.
@EXPORT_OK = qw( hello );
use strict; # of course

# Functions go here.  Let's be traditional
sub hello {
  print "Hello, World\n";
}

1;
[download]

use lib "/your/library/path";
use Foo::Bar qw(hello);
[download]

Now why would you do this? Well the classic syndrome that I see in shell programmers who pick up Perl is that they convert a mess of shell scripts into Perl scripts, and have the Perl scripts call each other like you would in shell. This leaves you with all of the limitations of shell programming, like difficulty handling errors, problems passing around structured data, etc.

What works better in my experience is to take your scripts and write each one as above as a module. Then you can replace the scripts with trivial ones that load up the right module, and call one function in it. But now when your scripts want to call on each other's functionality they can just load up the the right modules and call functions rather than execute external scripts. This gives you all of the flexibility, better performance, and opens up the door later for you to improve how you do your error handling or get fancier in how you store and pass data...

Now be warned as you go off that what I have given is but one common form of module. There are others. And you can easily get fancier (eg by using pod). But this should be enough to actually go and try writing some...

If your saying that perl is installed, but you don't have any man pages, i.e. if 'perldoc perl' or 'man perl' doesn't work, then something is broken. Or maybe the perl you run linked to another directory not in your path. (does 'ls -l $(which perl)' indicate, e.g. that you're running /usr/local/bin/perl but its just a link to /opt/perl/bin/perl, and '/opt/perl/bin' is not in your PATH, and '/opt/perl/man' is not in your MANPATH).