perl-module

I can not understand what is the difference/use case of EXPORT_OK vs EXPORT . Most resources mentions something in the lines of: @Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access its members. @EXPORT_OK does export of symbols on demand basis for selective list of symbols (subroutines and variables) of the module. But I really don't see the difference/meaning here. Can someone please provide a small fundamental example of the difference/usage of these 2

I am sure I have run this before but for the life of me cant find any reference in perlrun or through Google. Hopefully some of the perl boffins here will be able to answer it. When running a perl one liner with the -ne switch. Is there an option to have the code, that perl will compile, to be outputted to the console? So if I run: crontab -l | perl -ne 'print if /^00/' Then Perl will compile this to: while(<>){ print if /^00/; } I am sure there is a way to have perl spit out the code its going to use including any begin or end blocks. hopefully someone knows how. You may be thinking of the B:

If my Perl code has a production code location and "beta" code location (e.g. production Perl code us in /usr/code/scripts , BETA Perl code is in /usr/code/beta/scripts ; production Perl libraries are in /usr/code/lib/perl and BETA versions of those libraries are in /usr/code/beta/lib/perl , is there an easy way for me to achieve such a setup? The exact requirements are: The code must be THE SAME in production and BETA location. To clarify, to promote any code (library or script) from BETA to production, the ONLY thing which needs to happen is literally issuing cp command from BETA to prod

What's the best way to programatically discover all of the subroutines a perl module has? This could be a module, a class (no @EXPORT), or anything in-between. Edit: All of the methods below look like they will work. I'd probably use the Class::Sniff or Class::Inspector in production. However, Leon's answer is marked as 'accepted' since it answers the question as posed, even though no strict 'refs' has to be used. :-) Class::Sniff may be a good choice as it progresses; it looks like a lot of thought has gone into it. sub list_module { my $module = shift; no strict 'refs'; return grep { defined

What is the Difference between .pm (Perl module) and .pl (Perl script) file? Please also tell me why we return 1 from file. If return 2 or anything else, it's not generating any error, so why do we return 1 from Perl module? At the very core, the file extension you use makes no difference as to how perl interprets those files. However, putting modules in .pm files following a certain directory structure that follows the package name provides a convenience. So, if you have a module Example::Plot::FourD and you put it in a directory Example/Plot/FourD.pm in a path in your @INC , then use and