Free config software for linux

Config::Model::ValueComputer is a Perl module that provides configuration value computation.

SYNOPSIS

my $model = Config::Model->new() ;

$model ->create_config_class
(
name => "Master",
element
=> [
[qw/av bv/] => {type => leaf,
value_type => integer,
},
compute_int
=> { type => leaf,
value_type => integer,
compute => [ $a + $b, a => - av, b => - bv ],
min => -4,
max => 4,
},
[qw/sav sbv/] => {type => leaf,
value_type => string,
},
compute_string =>
=> { type => leaf,
value_type => string,
compute => [ meet $a and $b, a => - sav, b => - sbv ],
},
]
) ;

system-config-printer purpose is to configure a CUPS server (often the local machine) using the CUPS API. The tool is written in Python, using pygtk for the graphical parts and with some Python bindings (pycups) for the CUPS API.
It is largely the same as using the CUPS web interface for configuring printers, but has the advantage of being a native application rather than a web page. It appears in the Fedora menu under System -> Administration -> Printing.
As a result of using the CUPS API the tool is able to configure remote CUPS instances and is not limited to configuring CUPS on the local machine. The CUPS library providing the API uses HTTP and IPP to communicate with the CUPS server.
Enhancements:
- Several improvements for the new-printer wizard have been made, and assorted bugs have been fixed.

Perl::Critic::Config is a Perl module to find and load Perl::Critic user-preferences.

Perl::Critic::Config takes care of finding and processing user-preferences for Perl::Critic. The Config object defines which Policy modules will be loaded into the Perl::Critic engine and how they should be configured. You should never really need to instantiate Perl::Critic::Config directly because the Perl::Critic constructor will do it for you.

CONSTRUCTOR

new( [ -profile => $FILE, -severity => $N, -theme => $string, -include => @PATTERNS, -exclude => @PATTERNS, -single-policy => $PATTERN, -top => $N, -only => $B, -strict-profile => $B, -force => $B, -verbose => $N, -color => $B ] )
new()

Returns a reference to a new Perl::Critic::Config object. The default value for all arguments can be defined in your .perlcriticrc file. See the "CONFIGURATION" section for more information about that. All arguments are optional key-value pairs as follows:

-profile is a path to a configuration file. If $FILE is not defined, Perl::Critic::Config attempts to find a .perlcriticrc configuration file in the current directory, and then in your home directory. Alternatively, you can set the PERLCRITIC environment variable to point to a file in another location. If a configuration file cant be found, or if $FILE is an empty string, then all Policies will be loaded with their default configuration. See "CONFIGURATION" for more information.
-severity is the minimum severity level. Only Policy modules that have a severity greater than $N will be loaded into this Config. Severity values are integers ranging from 1 (least severe) to 5 (most severe). The default is 5. For a given -profile, decreasing the -severity will usually result in more Policy violations. Users can redefine the severity level for any Policy in their .perlcriticrc file. See "CONFIGURATION" for more information.
-theme is special string that defines a set of Policies based on their respective themes. If -theme is given, only policies that are members of that set will be loaded. See the "POLICY THEMES" section for more information about themes. Unless the -severity option is explicitly given, setting -theme causes the -severity to be set to 1.
-include is a reference to a list of string @PATTERNS. Policies that match at least one m/$PATTERN/imx will be loaded into this Config, irrespective of the severity settings. You can use it in conjunction with the -exclude option. Note that -exclude takes precedence over -include when a Policy matches both patterns.
-exclude is a reference to a list of string @PATTERNS. Polices that match at least one m/$PATTERN/imx will not be loaded into this Config, irrespective of the severity settings. You can use it in conjunction with the -include option. Note that -exclude takes precedence over -include when a Policy matches both patterns.
-single-policy is a string PATTERN. Only the policy that matches m/$PATTERN/imx will be used. This value overrides the -severity, -theme, -include, -exclude, and -only options.
-top is the maximum number of Violations to return when ranked by their severity levels. This must be a positive integer. Violations are still returned in the order that they occur within the file. Unless the -severity option is explicitly given, setting -top silently causes the -severity to be set to 1.
-only is a boolean value. If set to a true value, Perl::Critic will only choose from Policies that are mentioned in the users profile. If set to a false value (which is the default), then Perl::Critic chooses from all the Policies that it finds at your site.
-strict-profile is a boolean value. If set to a true value, Perl::Critic will make certain warnings about problems found in a .perlcriticrc or file specified via the -profile option fatal. In particular, Perl::Critic normally only warns about profiles referring to non-existent Policies, but this option makes this situation fatal.
-force controls whether Perl::Critic observes the magical "## no critic" pseudo-pragmas in your code. If set to a true value, Perl::Critic will analyze all code. If set to a false value (which is the default) Perl::Critic will ignore code that is tagged with these comments. See "BENDING THE RULES" for more information.
-verbose can be a positive integer (from 1 to 10), or a literal format specification. See Perl::Critic::Violations for an explanation of format specifications.
-color is not used by Perl::Critic but is provided for the benefit of perlcritic.

MRTG::Config is a Perl module for parsing MRTG configuration files.

WARNING

This module, while reliable right now, is still in ALPHA stages of development... The API/methods may change. Behaviors of methods will almost certainly change. The internal structure of data will change, as will many other things.

I will try to always release working versions, but anyone who expects their code that uses this module to continue working shouldnt... until I remove this warning.

SYNOPSIS

Ever have the need to parse an MRTG config file? I have. I needed to parse lots and lots of them. Using the functions built-in to MRTG_lib was too slow, too complex, and used too much RAM and CPU time for my poor web server to handle - and the data structures MRTG_lib built were way more complex than I needed.

MRTG::Config can load and parse MRTG and MRTG-style confiuguration files very quickly, and the parsed directives, targets and values can be located, extracted, and manipulated through an OO interface.

This module is intended to focus on correctly parsing the format of an MRTG configuration, regardless of whether or not the directives and values, etc. are valid for MRTG. I am using both the parsing behavior of MRTG_libs readcfg() function and the description of the format on the MRTG website as my guidelines on how to correctly parse these configuration files. I am still a short way off that goal, but this module is currently being used in a production environment with great success!

PLEA FOR MERCY

I plan on adding to this documentation and making it better organized soon, but Im willing to answer questions directly in the mean time. Also, this is my first module, written in a hurry to appease some disgruntled engineers. I do plan on continuing to improve it, so any input, positive or negative is certainly welcome!

USAGE EXAMPLE

use MRTG::Config;

my $cfgFile = mrtg.cfg;
my $persist_file = mrtg.cfg.db;

my $mrtgCfg = new MRTG::Config;

$mrtgCfg->loadparse($cfgFile);

# Want to store the parsed data for use later or by
# another program?
$mrtgCfg->persist_file($persist_file);
$mrtgCfg->persist(1);

foreach my $tgtName (@{$mrtgCfg->targets()}) {
my $tgtCfg = $mrtgCfg->target($tgtName);
# Lets assume every target has a Title.
print $tgtCfg->{title} . "n";
}

# globals() has some, um, interesting things you
# should know. Please read about it below...
my $globalCfg = $mrtgCfg->globals();

# Lets assume WorkDir is set.
print $globalCfg->{workdir} . "n";

Edit Config Files is an extension that allows you to edit config files.

Edit configuration files with your favorite editor from Toolbar or Tools menu.

Remove the menu icon

Add the following to userChrome.css:

#editconfigfiles-menu
{
list-style-image:none !important;
}

Config::Model::WarpedThing is a base class for warped classes.

SYNOPSIS

use base qw/Config::Model::WarpedThing/ ;

This class must be inherited by all classes that can be warped by Config::Model::Value. This class provides a set of methods that are expected by a warp master from a warped class.

Currently this class is inherited by Config::Model::Value, Config::Model::AnyId and Config::Model::WarpedNode.

WarpThing does not provide a constructor.

App::Conf::File is a Perl module to load and access configuration data.

SYNOPSIS

use App::Conf;

$config = App::Conf->new();
$config = App::Conf->new(configFile => $file);
print $config->dump(), "n"; # use Data::Dumper to spit out the Perl representation

# accessors
$property_value = $config->get($property_name);
$branch = $config->get_branch($branch_name); # get hashref of properties

# on-demand loading helper methods (private methods)
$config->overlay($config2); # merge the two config structures using overlay rules
$config->overlay($config1, $config2); # merge $config2 onto $config1
$config->graft($branch_name, $config2); # graft new config structure onto branch

# By convention, the configurations for each App-Context service will be located
# two levels under the hash ref as shown.

$config->{Conf} # config settings for all Conf services
$config->{Conf}{default} # config settings for the default Conf service
$config->{Security} # config settings for all Security services
$config->{Security}{default} # config settings for the default Security service
$config->{Template}{tt} # config settings for the Template service named "tt"

# The default driver (if "configClass" not supplied) reads in a Perl
# data structure from the file. Alternate drivers can read a Storable,
# unvalidated XML, DTD-validated XML, RDF-validated XML, or any other
# file format or data source anyone cares to write a driver for.

$conf = {
Standard => {
Log-Dispatch => {
logdir => /var/p5ee,
}
},
Authen => {
passwd => /etc/passwd,
seed => 303292,
},
};

# A comparable unvalidating XML file would look like this.

< conf>
< Standard>
< Log-Dispatch logdir="/var/p5ee"/>
< /Standard>
< Authen passwd="/etc/passwd" seed="303292"/>
< /conf>

# A comparable ini file (.ini) would look like this.

[Standard.Log-Dispatch]
logdir = /var/p5ee
[Authen]
passwd = /etc/passwd
seed = 303292

# A comparable Java properties-like file would look like this.

Standard.Log-Dispatch.logdir = /var/p5ee
Authen.passwd = /etc/passwd
Authen.seed = 303292

Java::SJ::Config is a Perl module that represents SJ Configuration File.

It uses XML::XPath to parse configuration files and generates objects to represent the directives.

Unless youre working on the module what you really want to know is what directives are allowed and their meaning. Youre in luck, its below.

VARIABLES

The following variables and their relevant defaults are used by the system. These defaults have been chosen to make it as easy as possible to install SJ on a fairly standard UNIX system and have logs, and directories in places that you would expect to find them.

The full paths that will be used if every default is in effect is also shown below.
dir.base - default /usr/local - full /usr/local

The base directory for the system. This directory is used in conjunction with defaults to find directories if they have not been defined elsewhere.
dir.lib - default ${dir.base}/lib/sj - full /usr/local/lib/sj

The directory to find jar files in.
dir.pid - default ${dir.base}/var/run - full /usr/local/var/run

The directory to store PID files in.
dir.log - default ${dir.base}/var/log/sj - full /usr/local/var/log/sj

The directory to store log files in
dir.script - default ${dir.base}/var/sj/script - full /usr/local/var/sj/script

The directory to store generated script files in.
dir.tmp - default &File::Spec::Functions::tmpdir - full N/A (depends on system)

The directory to store temporary files in.
app.name - no default

The name of the application
app.class - no default

The class file for the application
vm.default - Defined by whichever VM has default=true attribute

The default VM tag to use if none supplied by the application