Provided by: python-cliapp_1.20130808-1_all bug

NAME

       cliapp - config file and option conventions for Python command line framework

DESCRIPTION

       cliapp  is  a Python programming framework for writing command line applications for Unix-
       like operating systems.  This manual page  describes  the  conventions  for  configuration
       files and command line parsing provided by cliapp.

       Configuration  file  variables  and  command  line  options  are handled by cliapp under a
       uniform abstraction: every setting is available both in configuration  files  and  command
       line  options.  There are a few settings, provided by the framework itself, which are only
       available on the command line.  For example, --help outputs a short help text, listing all
       the available options, and --dump-config outputs a list of current configuration settings.

       Command line parsing follows GNU conventions: short options start with a single dash, long
       options with two dashes, and options may be used anywhere on the command line.  The  order
       of  options  versus  non-options  does  not  matter.  The exception is some of the options
       provided by the framework, which are executed immediately when found, and may  be  prevent
       the  rest  of the options from being parsed.  (--dump-config is one of these, so use it at
       the end of the command line only.)  Use -- on the  command  line  to  signal  the  end  of
       options: no arguments after that are considered to be option.

       Some  settings  may  have  aliases, which can be only a single character, and in that case
       they're parsed as single-character option names.

       Some applications have subcommands, which means that the first non-option argument is used
       to  tell the application what to do.  This is similar to what many version control systems
       do, for example CVS, svn, bzr, and git.  Options are  global,  and  are  not  specific  to
       subcommands.   Thus,  --foo  means  the same thing, regardless of what subcommand is being
       used.

   Configuration files
       Configuration files use INI file syntax.  All the settings are in  the  [config]  section.
       Other sections are allowed, but it is up to the application to give meaning to them.

       Multiple configuration files may be read.  Settings from later ones override settings from
       earlier ones.  Options override settings from the configuration files.

   String list settings
       Some settings may be a list of values (each value being a  string).   For  example,  there
       might  be a setting for patterns to search for, and multiple patterns are allowed.  On the
       command line, that happens by using the option multiple times.  In the configuration file,
       all  values  are given on one line, separated by commas.  This is a non-standard extension
       to the INI file syntax.  There is no way to escape commas.

       Example:

              [config]
              pattern = foo, bar, foobar

   Boolean (true/false or on/off or yes/no) settings
       When a setting can be either on or off, it's called a Boolean setting.  Such settings  are
       turned  off  by  default,  and  turned on if used on the command line.  In a configuration
       file, they need to be set to a value: if the value is one of yes, on, true, or the  number
       1, the setting is turned on.  Any other value means it is turned off.

              [config]
              verbose = true
              attack-kittens = no

       This turns the verbose setting on, but does not launch attack kittens.

       For  every  boolean setting, two command line options are added.  If the setting is called
       foo, the option --foo will turn the setting on,  and  --no-foo  will  turn  it  off.   The
       negation  is  only usable on the command line: its purpose is to allow the command line to
       override a setting from the configuration file.

   Logging and log files
       Programs using cliapp automatically support several options  for  configuring  the  Python
       logging module.  See the --help output for options starting with log for details.  Logging
       can happen to a file or the system log.  Log files can be rotated automatically  based  on
       size.

       The  --trace  option  enables  additional  debug logging, which is usually only useful for
       programmers.  The option configures the tracing library for  Python,  by  Lars  Wirzenius,
       which allows logging values of variables and other debug information in a way that is very
       lightweight when the tracing is turned off.  The option specifies for  which  source  code
       files  to  turn  on  tracing.   The  actual  logging happens via the normal Python logging
       facilities, at the debug level.

   Python profiling support
       You can run the application under the Python profiler (cProfile) by setting an environment
       variable.   The name of the variable is FOO_PROFILE, where FOO is the name of the program,
       as set by the application code or determined by cliapp automatically.  The  value  of  the
       environment  variable  is  the  name  of  the file to which the resulting profile is to be
       written.

   Manual page generation
       cliapp can generate parts of a manual page: the SYNOPSIS and OPTIONS sections.   It  fills
       these  in automatically based on the subcommand and settings that a program supports.  Use
       the --generate-manpage=FILE option, which is added automatically by cliapp.  The FILE is a
       manual  page  marked up using the -man macros for troff(1).  It should have empty SYNOPSIS
       and OPTIONS sections, and cliapp will fill them in.  The output it to the standard output.

       For example:

              foo --generate-manpage=foo.1.in > foo.1

       You would keep the source code for the manual page in  foo.1.in  and  have  your  Makefile
       produce foo.1 as shown above.

   Subcommands
       cliapp provides a way for the application to have subcommands, in the style of git(1), for
       example.  If the application is called foo, then it  can  have  subcommands  such  as  foo
       search,  and  foo  print.   The  application  gets  to define the name and meaning of each
       subcommand.  However, all settings (options and configuration files) are global,  and  can
       be used with all subcommands.  It is up to each subcommand what settings it obeys.

       If  there  are  any subcommands, cliapp automatically adds the help subcommand.  It allows
       you to get the help text for a specific subommand: foo help print, for example.

FILES

       cliapp reads a list of configuration files at startup, on behalf of the application.   The
       name  of the application is included in the name.  In the filenames below, the application
       name is progname.

       /etc/progname.conf
              Global configuration file.

       /etc/progname/*.conf
              More global configuration files.  These are read in ASCII sorted order.

       ~/.progname.conf
              Per-user configuration file.

       ~/.config/progname/*.conf
              More per-user configuration files.  Again, ASCII sorted order.

                                                                                        CLIAPP(5)