How to create and release new tools

• There are templates in the utiasl project named devframe.py and devframe.sh that may help to develop python or bash scripts. They are mainly meant to implement scripts to access devices but can serve as a starting point for other script developments as well.

  Each script should offer at least two options, -h for a brief help and -H for a detailed help. Calling a script without any options and parameters should result in a hint to use the help options, for example

  $ devstatus
  Use 'devstatus -h' for help,
  Use 'devstatus -H' for detailed help

  Naturally, this recommendation does no apply to pure interactive scripts without any options and parameters.

• Implement and test the new tool. Then add the source code to one of the SVN projects uti, utiasl, or utivme in your workspace.

• Add the file name of the tool to the Makefile of that SVN project.

• Commit tool and Makefile.

• Since Makefile releases all new scripts, check what would be released by executing

  $ make -n release
  install -g bel -m 775 -p relxml.py /common/usr/develop/scripts/vme/relxml.py
  install -g bel -m 775 -p vmeboot /common/usr/develop/scripts/vme/vmeboot
  install -g bel -m 775 -p mynewtool.sh /common/usr/develop/scripts/vme/mynewtool.sh

  If that's okay, just execute

  $ make release

  to release the new tool - and possibly others too. If you just want your new script to be released, copy the approriate line of the 'make -n' output to the command line

  $ install -g bel -m 775 -p mynewtool.sh /common/usr/develop/scripts/vme/mynewtool.sh

• The directory $DROOT/bin is part of bash's search path. If you place a script here, you can call it as a standard bash command without specifying any path.

  Since commands should have no extension and since many of the scripts need a special environment, the scripts are not placed directly at $DROOT/bin. Instead only (soft-) links or mini-sripts are placed there.

  • Links: If the standard environment is sufficient for the script and the script was released to, for example, utivme, just create a soft-link to the script at $DROOT/bin.

    $ cd $DROOT/bin
    $ ln -s $utivme/mynewtool.sh mynewtool
    $ ls -l mynewtool
    lrwxrwxrwx 1 kain 39 Aug 12 2010 mynewtool -> /common/usr/develop/scripts/vme/mynewtool.sh

    Note that the link has no extension!

  • Mini-scripts: If the script needs a special environment, for example an extended LD_LIBRARY_PATH, create a mini-script at $DROOT/bin named mynewtool that looks approximately like this:

    #! /bin/bash
    . ${uti}/defaults.sh
    ${utivme}/mynewtool.sh "$@"

    The defaults.sh adds $libasl64 and $libmsg64 to the LD_LIBRARY_PATH before calling mynewtool.sh. Additional or other settings may be applied here. Note the necessary dot in front of ${uti}/defaults.sh. The "$@" passes all command line options and parameters to the script.

    Note that the mini-script has no extension!

• Scripts that are valid only for the VME layer, e.g. ecload, should be part of utivme.

  Scripts that are valid for all layers (VME, asl, uIOC, etc.), e.g. devstatus, should be part of utiasl.

  Device Access independent scripts, e.g. gendocu, should be part of uti.