Re: [tlug] cron and lftp problems

[Josh Glover <jmglov@example.com>]

On Wed, 26 Jan 2005 07:07:21 -0800 (PST), Jake Morrison
<jake_morrison@example.com> wrote:
 
> --- Josh Glover <jmglov@example.com> wrote:
>
> > I put a bunch of "constants" at the top of my scripts:
> >
> > AWK=/bin/awk
> > CAT=/bin/cat
> > GREP=/bin/grep
> > SCP=/usr/bin/scp
> > SED=/bin/sed
> > SSH=/usr/bin/ssh
> >
> > And then, my commands look like this:
> >
> > servers=`${CAT} ${file} | ${SED} -e 's/\t/  /g' | ${AWK} '{ print $1
> > }'`
> > for i in ${servers}; do
> >   ${SSH} $i ${GREP} foo ${foofile}
> >   if [ $? -ne 0 ]; then
> >     ${SCP} ${foofile} $i:${foofile}
> >   fi
> > done
> 
> Josh, don't scare the guy :-)

That is like telling a dog not to bark (or wan-wan, depending on the
culture): he *can* stop, but he doesn't really want to! ;)

> Actually, variables are a great idea. But I don't end up using
> them that much for commands in shell scripts. I find that if
> the script gets complicated enough that I need some specific
> feature of grep or tar that only exists in the GNU version
> (installed in /usr/local or /opt or ...), it is probably better
> just to rewrite it in perl or python.

When I was working as a sysadmin, I assembled a small army of
automatons to do my work for me. Most of these were simple, Bourne
shell scripts that would run on any machine, with the crappiest of the
crappy versions of the Unix binutils. The only portability problem
that I would run into is that on Solaris, things like rsync were
likely to be found in /usr/local/bin or /opt/sfw/bin, whereas on Linux
systems, they tended to be in /usr/bin.

So my trivial variable-ising of command names proved the most powerful
portability design tool that I had! (Except for my C macros that would
detect the endian-ness of a host, and flip bytes as needed, of course!
;)

> Makefiles, on the other hand....

Speaking of which, I feel that this is a good time to reveal to the
world my Magnum Opus (or is that "Magnificent Octopus"?[1]): OSDT, the
Open Source Distribution (or Development, if you'd rather) Toolkit.

It includes a tool, osdt-new-project, that can create a new skeleton
directory for a project and optionally import it into a CVS or Subversion
repository:

osdt-new-project foo ~/ opensource --svnroot ~/svnroot

This would create a project skeleton for a project named "foo", in your
home directory, using project skeleton "opensource", and import it into a
Subversion repository rooted at ~/svnroot. (The repository is created if
it does not exist, if possible.) The contents of the new project directory
will be:

trunk
trunk/AUTHORS
trunk/TODO
trunk/VERSION
trunk/ChangeLog
trunk/COPYING
trunk/README
trunk/Makefile
branches
tags

(This is the standard Subversion layout, which can be suppressed with
the --svnflat option to osdt-new-project, which would result in a "flat"
CVS-style import, just containing the files in the top-level directory.)

The files are created from templates to provide a reasonable starting
point for a new project.

Which brings us to the other useful tool included in the OSDT distribution,
osdt-new-file, which creates a file from a template. This can be very useful
when you are working on a project and realise that you need a new source
file. You can just run osdt-new-file, like so:

osdt-new-file c-program foo.c

This creates a file named foo.c with the following contents:


/* =========================================================================
 * File: foo.c
 *
 * Copyright (c) 2005 and onwards, Josh Glover <jmglov@example.com>
 *
 * LICENCE:
 *
 *   This file is distributed under the terms of the BSD-2 License.
 *   See the COPYING file, which should have been distributed with
 *   this file, for details. If you did not receive the COPYING file,
 *   see:
 *
 *   http://www.jmglov.net/opensource/licenses/bsd.txt
 *
 * DESCRIPTION:
 *
 *   __DESCRIPTION__
 *
 * USAGE:
 *
 *   foo --help
 *
 * EXAMPLES:
 *
 *   __EXAMPLES__
 *
 * TODO:
 *
 *   - Nothing, this code is perfect
 *
 * DEPENDENCIES:
 *
 *   __DEPENDENCIES__
 *
 * MODIFICATIONS:
 *
 *   Josh Glover <jmglov@example.com> (2005/01/26): Initial revision
 * =========================================================================
 */

// Standard library includes
#include <stdio.h>
#include <string.h>


// Function prototypes
// ---------------------------------------------------------------------------


static int usage( const int retval );


// ---------------------------------------------------------------------------


// Main program
// ---------------------------------------------------------------------------


/** Function: main()
 *
 * Main program.
 *
 * Parameters:
 *
 *   argc - number of command-line arguments (including the full pathname of
 *          the executable)
 *   argv - command-line arguments (including the full pathname of the
 *          executable)
 *
 * Returns:
 *
 *   0 on success, UNIX return value on failure
 */

int main( const int argc, const char *argv[] ) {

  int i; // counter

  // Parse arguments
  for (i = 0; i < argc; i++) {

    // -? / --help
    if (strcmp( argv[i], "-?" ) == 0 || strcmp( argv[i], "--help" ) == 0)
      return usage( 0 );

  } // for (parsing arguments)

  return 0;

} // main()


// ---------------------------------------------------------------------------


// Functions
// ---------------------------------------------------------------------------


/** Function: usage()
 *
 * Prints a usage message.
 *
 * Parameters:
 *
 *   retval - if non-zero, the usage message will be printed to standard
 *            error; otherwise, it will be printed to standard out
 *
 * Returns:
 *
 *   The retval parameter
 */

static int usage( const int retval ) {

  fprintf( retval ? stderr : stdout, "Usage: foo __USAGE__" );

  return retval;

} // usage()


// ---------------------------------------------------------------------------


You can also set macros on the command-line:

osdt-new-file USAGE='--help' DESCRIPTION='Test program for libfoo' \
 EXAMPLES='foo --help' DEPENDENCIES='GNU GCC' c-program foo.c

This will replace "__USAGE__" in the resulting file with "--help",
"__DESCRIPTION__" with "Test program for libfoo", etc.

The OSDT tools read two XML config files when they start up, a
side-wide one and a user-specific one, so you can set permanent
macros. Once you have OSDT installed, the following command will
create a user-specific config file for you with common macros set:

osdt-new-file \
  AUTHOR='Your Name' \
  AUTHOR_EMAIL='your.email@example.com' \
  osdt-config ~/.osdt/config.xml

You can grab the latest release of OSDT from:
http://sourceforge.net/project/showfiles.php?group_id=113934

--Josh "dear God this email got long!" Glover

[1] http://hem.passagen.se/dunsel/ba3-2.htm