Jump to letter: [ ABCDEFGHIKLMNOPRSTWXY ]

perl-Getopt-ArgvFile: Getopt-ArgvFile - interpolates script options from files into @ARGV or another array

Name:	perl-Getopt-ArgvFile	Vendor:	Jochen Stenzel <Eltmailto:perl{%}jochen-stenzel{*}deEgt>
Version:	1.10	License:	Artistic
Release:	1	URL:	http://www.cpan.org

Summary

This module simply interpolates option file hints in @ARGV by the contents of the pointed files. This enables option reading from *files* instead of or additional to the usual reading from the command line. Alternatively, you can process any array instead of @ARGV which is used by default and mentioned mostly in this manual. The interpolated @ARGV could be subsequently processed by the usual option handling, e.g. by a Getopt::xxx module. Getopt::ArgvFile does *not* perform any option handling itself, it only prepares the array @ARGV. Option files can significantly simplify the call of a script. Imagine the following: =over 4 =item Breaking command line limits A script may offer a lot of options, with possibly a few of them even taking parameters. If these options and their parameters are passed onto the program call directly, the number of characters accepted by your shells command line may be exceeded. Perl itself does *not* limit the number of characters passed to a script by parameters, but the shell or command interpreter often *sets* a limit here. The same problem may occur if you want to store a long call in a system file like crontab. If such a limit restricts you, options and parameters may be moved into option files, which will result in a shorter command line call. =item Script calls prepared by scripts Sometimes a script calls another script. The options passed onto the nested script could depend on variable situations, such as a users input or the detected environment. In such a case, it *can* be easier to generate an intermediate option file which is then passed to the nested script. Or imagine two cron jobs one preparing the other: the first may generate an option file which is then used by the second. =item Simple access to typical calling scenarios If several options need to be set, but in certain circumstances are always the same, it could become sligthly nerveracking to type them in again and again. With an option file, they can be stored *once* and recalled easily as often as necessary. Further more, option files may be used to group options. Several settings may set up one certain behaviour of the program, while others influence another. Or a certain set of options may be useful in one typical situation, while another one should be used elsewhere. Or there is a common set of options which has to be used in every call, while other options are added depending on the current needs. Or there are a few user groups with different but typical ways to call your script. In all these cases, option files may collect options belonging together, and may be combined by the script users to set up a certain call. In conjunction with the possiblity to *nest* such collections, this is perhaps the most powerful feature provided by this method. =item Individual and installationwide default options The module allows the programmer to enable user setups of default options; for both individual users or generally *all* callers of a script. This is especially useful for administrators who can configure the *default* behaviour of a script by setting up its installationwide startup option file. All script users are free then to completely forget every already configured setup option. And if one of them regularly adds certain options to every call, he could store them in his *individual* startup option file. For example, I use this feature to make my scripts both flexible *and* usable. I have several scripts accessing a database via DBI. The database account parameters as well as the DBI startup settings should not be coded inside the scripts because this is not very flexible, so I implemented them by options. But on the other hand, there should be no need for a normal user to pass all these settings to every script call. My solution for this is to use *default* option files set up and maintained by an administrator. This is very transparent, most of the users know nothing of these (documented ;-) configuration settings ... and if anything changes, only the option files have to be adapted. =back

Changelog

* Thu Sep 14 21:00:00 2006 cmc@vosill.math.hmc.edu

- Initial build.

Listing created by RepoView-0.5.2