Perl use where is module

You could say use lib ". More annoyingly, it's the current directory of the Perl process, not the directory that the script was installed into, which makes it completely unreliable. If you create a program plus some modules for that program to use, it will work while you're developing, but it won't work when you aren't running in the directory the files live in.

One solution for this is to use the standard FindBin module: use FindBin; where was script installed? Don't use this for security purposes, because malicious programs can usually deceive it if they try hard enough. But unless you're intentionally trying to break the module, it should work as intended. You can then use the lib pragma to add that directory to your INC , thus producing an executable-relative path. Make programs on complex installations start more quickly.

Even though you can manipulate where Perl looks for modules INC at runtime according to your needs [Hack 29] , and even though you can use thousands of modules from the CPAN, your system has to find and load these modules. For a short-running, repeated program, this can be expensive, especially if you have many paths in INC from custom testing paths, sitewide paths, staging servers, business-wide repositories, and the like. One approach is to resolve all of the paths just once, and then use your program as normal.

That works here, too. Thus Perl attempts to load the module as normal. Put Devel::Presolve somewhere in your path. Then run your slow-starting program while loading the module. Redirect the output to a file of your choosing:. If you do the latter, put the file in a directory at the front of INC , lest you erase any performance gains. For short-running programs where startup time can dwarf calculation time, it may, depending on how complex your INC is. Be especially careful that upgrading Perl or installing new versions of modules may invalidate this cache—it is a cache—and cause strange errors.

Curb your addiction to explicit use statements. Most experienced Perl programmers rely on a core set of modules and subroutines that they use in just about every application they create.

If those documents contain lists of files that you need to manipulate, then you probably use File::Spec or File::Spec::Functions as well, and perhaps File::Find too. Maybe you need to verify and manipulate dates and times on those files, so you regularly pull in half a dozen of the DateTime modules. You might also like to have Smart::Comments instantly available [Hack 54] to simplify debugging. Of course, you always specify use strict and use warnings , and probably use Carp as well.

This adds up to a tediously long list of standard modules, most of which you need to load every time you write a new application:. Of course, that fails dismally. What you really need is a way to create a far more cunning module: one that cuts-and-pastes any use statements inside it into any file that uses the module. As its name suggests, this module is a source filter that converts what follows it into a macro.

Perl then replaces any subsequent use of that macro-ized module with the contents of the module. The Toolkit module also on CPAN allows you to specify a collection of standard module inclusions as separate files in a standard directory structure. Once you have them set up, you can automatically use them all just by writing:. For example, you can tell Toolkit not to always load:. That way, you can safely specify dozens of handy subroutines and modules in your standard toolkit, but only pay the loading costs for those you actually use.

Give tutorial readers example code to run, tweak, and examine. Reading code is one thing. Running code is another. Example code is wonderfully useful, but nothing beats playing with it—changing values, moving subroutines around, and seeing what happens if you touch just one more thing. You can escape having to explain the basics over and over again if that documentation includes working, runnable code that people can customize for their needs. Writing a POD-only tutorial is easy.

Better yet, if you run the tutorial from the command line, it writes out this program to a file of your choosing:. How does Pod::ToDemo know to write the file and exit? Further, what if someone accidentally uses SDL::Tutorial as a module within a real program—will it write or overwrite a file and throw an error? Pod::ToDemo has two tricks. The first is writing code that will execute when you run the demo file from the command line only.

That is, look three levels up the call stack. Why three levels? The next one up is the load of the demo module itself -M on the command line creates its own block.

The top level is the command-line invocation itself. This is the easy way to use Pod::ToDemo. Consider if you already show the example code within the tutorial, perhaps in one large chunk and perhaps not. Duplicating the code within the string to pass to Pod::ToDemo and the tutorial itself would be a mistake. In that case, generate the code however you like, pulling it out of the POD, and pass a subroutine reference to Pod::ToDemo.

The module will call that instead, when appropriate, letting you write the demo file as you like. This trick would also work to parameterize the demo file based on command-line arguments. Patch buggy modules without touching their source code. Until computers finally decide to do what we mean, not what we say, programs will have bugs.

Some you can work around. Others are severe enough that you have to modify source code. Instead of keeping local copies of externally managed code, sometimes patching that code from the outside is the simplest way to make your code work again. The relevant code might look something like:. Back in the main package, the odd-looking subroutine declaration merely declares the actual implementation of that subroutine. Doing this in two steps avoids a warning about using a symbol name only once.

Using local replaces the code only in your current dynamic scope, so any code you call from this scope will use this function instead of the old version. To replace the subroutine globally, use Parser as normal, but remove the line that starts with local. Replace it with no warnings 'redefine'; to avoid a different warning. This variant technique is highly useful in testing code.

Play London. The goal of the game, depending on who you ask, is either to prove that you have an incredibly deep knowledge of the CPAN or to get incredibly drunk. An alternate goal is to learn about modules you never even knew existed. Just try to remember them. The same applies if he managed to pull out a module name with four, five, or more parts. Domm picks up with X. Audrey drinks and names XML::Simple. Play continues counterclockwise to Domm, who needs to come up with something starting with S.

Try another beverage—hot tea is good, root beer is good, and anything with caffeine can change the rule for losing in interesting ways. Some variants of the game require Barbie to drink until he can name a module. This can take a while.

Die with style when something goes wrong. Yet there are times when you know you can handle certain types of exceptions, if not others. How would you like more context when you catch an exception?

Sure, if someone uses the Carp module you can sometimes get a stack trace. For example, consider the canonical example of a system call gone awry. Exception::Class lets you throw an exception as normal while making all of the information available through instance methods.

File::Exception subclasses Exception::Class::Base to add two more fields and a friendlier error message:. Exception::Class::Base uses this to initialize the object with the proper attributes. What are the other methods? Now instead of having to parse the string for potentially useful information, you can debug and, if possible, recover with better debugging information:.

Exception::Class objects are objects—so they can have relationships with each other. You can subclass them and make an entire hierarchy of exceptions, if your application needs them. You can also catch and redispatch them based on their type or any other characteristic you want. They still behave just like normal exceptions. Search the CPAN without leaving the command line. Besides that, you might not even have a network connection. Because you have that local copy, you can parse it, check the modules that match your search terms, and print the results.

Additionally you can check to see if any of them are installed already and highlight them. First, the code tries to find the local module list. This can be in several places. If that fails, the program performs the same check for CPAN. If so, it can highlight installed modules.

The code attempts to require the module to see if it is available. If so, the program must highlight the name with color, if available, or exclamation marks otherwise. Finally, the program prints the description and tries the next module. This hack also relies on 03modlist. First, the program could just die if the module list is too old. This is the simplest and most defeatist solution.

Second, you could write a cron job that periodically updates the module list. The main functionality of the FileLogger module is to:. Fourth, develop subroutines to handle logging functionality. We need a subroutine to open the log file for writing log messages. We need another subroutine to append log messages to the log file. We use print function to write log messages into the log file. Fifth, at the end of the FileLogger.

Perl used to require a module to return a true value when using from other programs.