Sponsored Content
Full Discussion: Distributing a perl script
Top Forums Shell Programming and Scripting Distributing a perl script Post 302440468 by forquare on Tuesday 27th of July 2010 09:35:59 AM
Old 07-27-2010
Distributing a perl script

Hi all,

I'm new to the world of Perl so may have gone about this in the wrong way (my background is mainly Java and Bash).

I have a Perl script (gallery.pl) which takes in various arguments (the only mandatory arguments is a directory full of images) and creates an HTML, standards compliant gallery. Seeing how images might be too big, I use the Image::Magick module to do any resizing that is necessary.

If I want to pass this script to a technically minded user to use then I'd just email the script or put it on my site for them to download and then they can sort out any modules they need to install.
However, what about non-technically minded users? How can I distribute my script in such a way that the end user doesn't have to care about missing dependancies?

I've thought about an installation script to install the main script under /opt/local/bin, could I use this installation script to install missing modules? If so, how might I do this?

I've tried looking at things like Module::AutoInstall and ExtUtils::MakeMaker but my interpretation is that these are only for modules, not for scripts.

Sorry to sound so dim about it all, but as I said, it's all rather new to me!

Many thanks,
Ben
 

7 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Distributing folders into set sizes

Is it possible to have a script watch a folder which contains other folders and split the contents into folders of under 700MB? Not sure if I explained that very well, but I have on my server an 'archive' folder where finished work is dropped, it is then burned to CD for storage and deleted, I... (3 Replies)
Discussion started by: redturbo
3 Replies

2. UNIX for Dummies Questions & Answers

Help with distributing scripts

Hi, I have written a series of BASH scripts that I have grouped together into a software package I distribute to other users in my field. The package consists of a "master script", which users modify to specify particular processing variables. Depending on the variables specified, and their... (5 Replies)
Discussion started by: msb65
5 Replies

3. Shell Programming and Scripting

calling a perl script with arguments from a parent perl script

I am trying to run a perl script which needs input arguments from a parent perl script, but doesn't seem to work. Appreciate your help in this regard. From parent.pl $input1=123; $input2=abc; I tried calling it with system("/usr/bin/perl child.pl $input1 $input2"); and `perl... (1 Reply)
Discussion started by: grajp002
1 Replies

4. Shell Programming and Scripting

executing perl script from another perl script : NOT WORKING

Hi Folks, I have 2 perl scripts and I need to execute 2nd perl script from the 1st perl script in WINDOWS. In the 1st perl script that I had, I am calling the 2nd script main.pl =========== print "This is my main script\n"; `perl C:\\Users\\sripathg\\Desktop\\scripts\\hi.pl`; ... (3 Replies)
Discussion started by: giridhar276
3 Replies

5. Shell Programming and Scripting

Perl : embedding java script with cgi perl script

Hi All, I am aware that html tags can be embedded in cgi script as below.. In the same way is it possible to embed the below javascript in perl cgi script ?? print("<form action="action.htm" method="post" onSubmit="return submitForm(this.Submitbutton)">"); print("<input type = "text"... (1 Reply)
Discussion started by: scriptscript
1 Replies

6. Shell Programming and Scripting

Distributing script projects, suggestions/ideas?

Heyas If you recall, not too long ago, i was asking about the GNU Autotools. The feedback on that was almost unisense, and me figured that it turned my (back then) +98% SHELL project into a +73% GROFF project... :( Felt a bit overhelmed, specialy since i didnt actualy use or need the true... (0 Replies)
Discussion started by: sea
0 Replies

7. Programming

PERL: In a perl-scripttTrying to execute another perl-script that SETS SOME VARIABLES !

I have reviewed many examples on-line about running another process (either PERL or shell command or a program), but do not find any usefull for my needs way. (Reviewed and not useful the system(), 'back ticks', exec() and open()) I would like to run another PERL-script from first one, not... (1 Reply)
Discussion started by: alex_5161
1 Replies
Module::Build::Compat(3pm)				 Perl Programmers Reference Guide				Module::Build::Compat(3pm)

NAME
Module::Build::Compat - Compatibility with ExtUtils::MakeMaker SYNOPSIS
# In a Build.PL : use Module::Build; my $build = Module::Build->new ( module_name => 'Foo::Bar', license => 'perl', create_makefile_pl => 'traditional' ); ... DESCRIPTION
Because "ExtUtils::MakeMaker" has been the standard way to distribute modules for a long time, many tools (CPAN.pm, or your system administrator) may expect to find a working Makefile.PL in every distribution they download from CPAN. If you want to throw them a bone, you can use "Module::Build::Compat" to automatically generate a Makefile.PL for you, in one of several different styles. "Module::Build::Compat" also provides some code that helps out the Makefile.PL at runtime. METHODS
create_makefile_pl($style, $build) Creates a Makefile.PL in the current directory in one of several styles, based on the supplied "Module::Build" object $build. This is typically controlled by passing the desired style as the "create_makefile_pl" parameter to "Module::Build"'s "new()" method; the Makefile.PL will then be automatically created during the "distdir" action. The currently supported styles are: traditional A Makefile.PL will be created in the "traditional" style, i.e. it will use "ExtUtils::MakeMaker" and won't rely on "Module::Build" at all. In order to create the Makefile.PL, we'll include the "requires" and "build_requires" dependencies as the "PREREQ_PM" parameter. You don't want to use this style if during the "perl Build.PL" stage you ask the user questions, or do some auto-sensing about the user's environment, or if you subclass "Module::Build" to do some customization, because the vanilla Makefile.PL won't do any of that. small A small Makefile.PL will be created that passes all functionality through to the Build.PL script in the same directory. The user must already have "Module::Build" installed in order to use this, or else they'll get a module-not-found error. passthrough (DEPRECATED) This is just like the "small" option above, but if "Module::Build" is not already installed on the user's system, the script will offer to use "CPAN.pm" to download it and install it before continuing with the build. This option has been deprecated and may be removed in a future version of Module::Build. Modern CPAN.pm and CPANPLUS will recognize the "configure_requires" metadata property and install Module::Build before running Build.PL if Module::Build is listed and Module::Build now adds itself to configure_requires by default. Perl 5.10.1 includes "configure_requires" support. In the future, when "configure_requires" support is deemed sufficiently widespread, the "passthrough" style will be removed. run_build_pl(args => @ARGV) This method runs the Build.PL script, passing it any arguments the user may have supplied to the "perl Makefile.PL" command. Because "ExtUtils::MakeMaker" and "Module::Build" accept different arguments, this method also performs some translation between the two. "run_build_pl()" accepts the following named parameters: args The "args" parameter specifies the parameters that would usually appear on the command line of the "perl Makefile.PL" command - typically you'll just pass a reference to @ARGV. script This is the filename of the script to run - it defaults to "Build.PL". write_makefile() This method writes a 'dummy' Makefile that will pass all commands through to the corresponding "Module::Build" actions. "write_makefile()" accepts the following named parameters: makefile The name of the file to write - defaults to the string "Makefile". SCENARIOS
So, some common scenarios are: 1. Just include a Build.PL script (without a Makefile.PL script), and give installation directions in a README or INSTALL document explaining how to install the module. In particular, explain that the user must install "Module::Build" before installing your module. Note that if you do this, you may make things easier for yourself, but harder for people with older versions of CPAN or CPANPLUS on their system, because those tools generally only understand the Makefile.PL/"ExtUtils::MakeMaker" way of doing things. 2. Include a Build.PL script and a "traditional" Makefile.PL, created either manually or with "create_makefile_pl()". Users won't ever have to install "Module::Build" if they use the Makefile.PL, but they won't get to take advantage of "Module::Build"'s extra features either. For good measure, of course, test both the Makefile.PL and the Build.PL before shipping. 3. Include a Build.PL script and a "pass-through" Makefile.PL built using "Module::Build::Compat". This will mean that people can continue to use the "old" installation commands, and they may never notice that it's actually doing something else behind the scenes. It will also mean that your installation process is compatible with older versions of tools like CPAN and CPANPLUS. AUTHOR
Ken Williams <kwilliams@cpan.org> COPYRIGHT
Copyright (c) 2001-2006 Ken Williams. All rights reserved. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO
Module::Build(3), ExtUtils::MakeMaker(3) perl v5.12.1 2010-04-26 Module::Build::Compat(3pm)
All times are GMT -4. The time now is 02:00 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy