| Name : perl-Getopt-ArgvFile
| |
| Version : 1.11
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp155.1.1
| Date : 2023-07-20 16:57:43
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Getopt-ArgvFile-1.11-lp155.1.1.src.rpm
|
| Size : 0.05 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Interpolates script options from files into @ARGV or another array
|
Description :
This module simply interpolates option file hints in AATTARGV 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 AATTARGV which is used by
default and mentioned mostly in this manual.
The interpolated AATTARGV 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 AATTARGV.
Option files can significantly simplify the call of a script. Imagine the
following:
* 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.
* 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.
* 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.
* 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.
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-G/15.5/noarch |
