Best way to call another perl file

derekstucki has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Best way to call another perl file by bitingduck (Deacon) on Apr 02, 2015 at 01:25 UTC
As anonymonk said, it's very easy to create a module (Re: How to creater your own Perl modules/libraries?) and then export whatever external functions you want with exporter. So easy that if you intend to keep the code around for more than a few minutes or will want to use the pdf generator stuff somewhere else that it's easier to create and use a module than to debug your other code where you've done it in some less modular way	[reply]
Re: Best way to call another perl file by LanX (Saint) on Apr 02, 2015 at 00:59 UTC
> each of the called files will need to be supplied with dynamic arguments and need to either create a PDF file and pass back the filename For an easy approach have a look at `do` `FILE` , this reads and evals another file in the same context, i.e. as if inserted in code. The "best" approach is using modules, but this requires more preparation. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)} PS: Je suis Charlie!	[reply] [d/l]
Re^2: Best way to call another perl file by Anonymous Monk on Apr 02, 2015 at 01:09 UTC
The "best" approach is using modules, but this requires more* preparation.* more? All the options are about equal amount of preparation ... name subs, name files ... name package ... about equal effort (save extra 100 keystrokes here there) zentara package/module tutorial FWIW, among all the options available, do is about the worst :)	[reply]
Re^3: Best way to call another perl file by karlgoethebier (Abbot) on Apr 02, 2015 at 17:50 UTC
"... do is about the worst" ~~It seems to be an ineradicable prejudice that `do $file` and its equivalent `eval qx(cat $file)` is bad practice.~~ It seems to be an ineradicable prejudice that `do $file` and its equivalent `eval qx(cat $file)` is bad practice per se. Anyway, for some details about the pro and cons recipe 8.16. in the Perl Cookbook is still a good source. Regards, Karl ŤThe Crux of the Biscuit is the Apostropheť	[reply] [d/l] [select]
Re^4: Best way to call another perl file by Anonymous Monk on Apr 02, 2015 at 19:52 UTC
Re^5: Best way to call another perl file by LanX (Saint) on Apr 02, 2015 at 20:34 UTC
Re: Best way to call another perl file by RonW (Parson) on Apr 01, 2015 at 23:36 UTC
Why separate scripts? They could be modules use'd by the main script by calling functions in the modules.	[reply]
Re: Best way to call another perl file (system) by Anonymous Monk on Apr 01, 2015 at 22:18 UTC
LOL! The simplest option is you tell the scripts what filename to write to, same as you tell it what filename to read -- Getopt::Long, so system $^X, 'foo.pl', '--infile', 'blah', '--outfile', 'blah'; Otherwise Capture::Tiny	[reply]
Re: Best way to call another perl file by derekstucki (Sexton) on Apr 02, 2015 at 19:44 UTC
Thanks for all the input so far. I thought about using modules, but I'd need a separate module for each, and so thought that that wouldn't be any more efficient. The file names of the secondary scripts would be stored in a database, with different ones being called on each run of the main script, based on user input. Should I still do that with modules? Adding each as a different sub in the same module sounds like far more of a maintenance nightmare long term, as a new file/database entry will likely be added every several months. Tell me if your experience differs, but adding a new file and database entry sounds more maintainable in the long run. Edit: To explain further, each of the called scripts is associated with a single PDF, filling it out according to info in the database. Each PDF is different enough to need its own logic on what goes where, thus its own script. If this is a dumb way of doing this, I would LOVE a better suggestion, as I don't really like this solution, but know it will work.	[reply]
Re^2: Best way to call another perl file by Anonymous Monk on Apr 02, 2015 at 20:22 UTC
Vague talk is vague and not examples You don't need to stuff everything into one file Here are commands Stucki::Command::Ro Stucki::Command::Sham Stucki::Command::Bo, they correspond to lib/Stucki/Command/Ro.pm `package Stucki::Command::Ro ; sub run { print "Ro ro ro-sham-bo, gently down the stream\n" } 1;` [download] They're loaded by by this module `package Stucki; use Module::Load qw/ load /; sub run { my( $shelf, $command, @rest ) = @_; my $plugin = "Stucki::Command::".$command; load $plugin; ## or dies $plugin->run( @rest ); } 1;` [download] So from commandline you might use `./stucki ro ast some mo corn` where stucki might be `#!/usr/bin/perl -- use Stucki::Frontend::CLI; Stucki::Frontend::CLI->run;` [download] And a stucki.cgi might be `#!/usr/bin/perl -- use Stucki::Frontend::CGI; Stucki::Frontend::CGI->run;` [download] And so on and so forth... Some examples of organizing such an "app": Ask, P5U, CPANPLUS/ CPANPLUS::Shell::Default / CPANPLUS::Shell::Tk / CPANPLUS::Shell::Wx App-Cme-1.002 Check or edit configuration data with Config::Model Config-Model-2.068 Create tools to validate, migrate and edit configuration files Config-Model-Approx-1.009 Approx configuration file editor Config-Model-Backend-Augeas-0.118 Read and write configuration data through Augeas Config-Model-CursesUI-1.104 Curses interface to edit config data through Config::Model Config-Model-Itself-1.243 Model editor for Config::Model Config-Model-LcdProc-2.042 Edit and validate LcdProc configuration file Config-Model-OpenSsh-1.236 OpenSSH config editor Config-Model-Tester-2.050 Test framework for Config::Model Config-Model-TkUI-1.345 Tk GUI to edit config data through Config::Model Config-Model-Xorg-1.106 Xorg configuration editor and validator cpan2pkg generating native linux packages from cpan App::CPAN2Pkg generating native linux packages from cpan App::CPAN2Pkg::Controller controller for cpan2pkg interface App::CPAN2Pkg::Lock Simple locking mechanism within cpan2pkg App::CPAN2Pkg::Module poe session to drive a module packaging App::CPAN2Pkg::Repository repository details for a given module App::CPAN2Pkg::Types types used in the distribution App::CPAN2Pkg::UI::Text text interface for cpan2pkg App::CPAN2Pkg::UI::Tk main cpan2pkg window App::CPAN2Pkg::Utils various utilities for cpan2pkg App::CPAN2Pkg::Worker poe session to drive a module packaging App::CPAN2Pkg::Worker::Mageia worker dedicated to Mageia distribution App::CPAN2Pkg::Worker::RPM worker specialized in rpm distributions math-image display some mathematical images App::MathImage math-image application module App::MathImage::Gtk2::AboutDialog App::MathImage::Wx::Main math-image wxWidgets main window App::MathImage::Tk::Main App::MathImage::Prima::Main more examples at Re: Recommendations for adding plugin/addon capability to a program and other places	[reply] [d/l] [select]
Re^3: Best way to call another perl file by derekstucki (Sexton) on Apr 02, 2015 at 22:09 UTC
This is perfect. Thank you!	[reply]