programs.cfg

The file programs.cfg contains programs written in other languages, with each program in its own stanza.

For example, you might have a programs.cfg #include file for a backup script (written in Bash):

///////////////////////////////////////////////////////////////////////////////
//
// backup_nightly_programs.cfg
//
///////////////////////////////////////////////////////////////////////////////

#if backupserver

backup_nightly.sh               // do nightly backups

        #!/bin/bash

        RSYNC=/usr/bin/rsync
        SSH=/usr/bin/ssh
        SCP=/usr/bin/scp

#  if athens | oslo

        # backup manchester's /var/www
        $RSYNC -vap --delete --rsh=$SSH manchester-bak:/var/www /arc2/manchester/var

...

        # backup /usr/local
        $RSYNC -vap --delete --rsh=$SSH warsaw-bak:/usr/local /arc2/warsaw/usr
        $RSYNC -vap --delete --rsh=$SSH manchester-bak:/usr/local /arc2/manchester/usr

...

#  endif

#  if athens

        # backup /var/www/html
        $RSYNC -vap --delete --rsh=$SSH manchester-bak:/var/www/html /var/www

        # backup /var/www/cgi-bin
        $RSYNC -vap --delete --rsh=$SSH manchester-bak:/var/www/cgi-bin /var/www

...

#  endif

#endif  // backupserver

///////////////////////////////////////////////////////////////////////////////
The benefits of managing external scripts from a central programs.cfg file include:  having centralized backups, diffing and doing checksums against the central copy, easy access to common program components, per-system customizations, no losing track of what you have written, greater understanding of the whole, etc.

In programs.cfg (or any of its #include files), the form of a program stanza is:

<program>       [path "<filepath>"]
                [mode <octal filemode> uid <number> gid <number>]
                <program statement>
                <program statement>                 
                   ...
Since programs may contain blank lines, what separates one program from another are program identifiers, listed in the first column.  The actual programs follow, on succeeding indented lines.  (See the discussion in Format about how to properly indent program lines.)

Specifying a program path is optional.  With no directory specified, the program will be installed in the =piktdir/lib/programs directory.  To override this, you can either prepend the program's stanza identifier with the directory, else include a path specification.

For example, this will install foobar.pl in =piktdir/lib/programs

foobar.pl       mode 750 uid 0 gid 0
        ...
this will install it in /usr/local/bin
/usr/local/bin/foobar.pl       mode 750 uid 0 gid 0
        ...
and this, too, will install it in /usr/local/bin
foobar.pl       path "/usr/local/bin/foobar.pl" mode 750 uid 0 gid 0
        ...
This latter method, using the "path" keyword, is preferred over the previous method, using the entire filepath as the stanza identifier.  (See also the discussion in Format on how to handle identically named programs.)

Specifying a program file's mode (e.g., 755), uid (e.g., 0), and gid (e.g., 1) is optional.  If they are absent, the defaults are 750, 0 & 0.

Since other programs may contain their own comments as well as special character sequences, Pikt comment stripping is handled in a special way.  See piktc.

Refer to the sample programs.cfg for more examples.

prev page 1st page next page
 
Home | FAQ | News | Intro | Samples | Tutorial | Reference | Software
Developer's Notes | Licensing | Authors | Pikt-Users | Pikt-Workers | Related Projects | Site Index | Privacy Policy | Contact Us
Page best viewed at 1024x768 or greater.   Page last updated 2019-01-12.   This site is PIKT® powered.
Copyright © 1998-2019 Robert Osterlund. All rights reserved.
Home FAQ News Intro Samples Tutorial Reference Software
PIKT Logo
PIKT Page Title
View sample
piktd.conf
config file