views:

255

answers:

5

Is there a convention for documenting shell scripts' parameters?

For example:

#!/usr/bin/env bash

# <description>
#
# Usage:
#  $ ./myScript param1 [param2]
# * param1: <description>
# * param2: <description>

A few things I don't like about this particular template:

  • the script's file name (myScript) appears within the file itself
  • parameter description seems weird
  • the leading space before $ is visually useful, but can lead to confusion in languages with block comments, causing some validation tools to complain about mixed/inconsisent indentation (e.g. spaces in this block, tabs for code - provided one prefers tabs, of course)

Are there any guidelines on this?

+1  A: 

I would rather write:

Usage: `basename $0` [option1]|[option2] param1
  Options:
   - option1:  .....
   - option2:  .....
  Parameters:
   - param1:   .....

Try to look at the way help is formatted for standard UNIX utilities (ls --help, for instance)

Varkhan
A: 

I would recommend making your script automatically print usage (if it shouldn't be run without arguments):

#!/usr/bin/env bash

if [ ${#@} == 0 ]; then
    echo "Usage: $0 param1 [param2]"
    echo "* param1: <description>"
    echo "* param2: <description>"
fi
sysrqb
+1  A: 

The Vim bash IDE that does this:

#!/bin/bash
#===============================================================================
#
#          FILE:  test.sh
#
#         USAGE:  ./test.sh
#
#   DESCRIPTION:
#
#       OPTIONS:  ---
#  REQUIREMENTS:  ---
#          BUGS:  ---
#         NOTES:  ---
#        AUTHOR:  Joe Brockmeier, [email protected]
#       COMPANY:  Dissociated Press
#       VERSION:  1.0
#       CREATED:  05/25/2007 10:31:01 PM MDT
#      REVISION:  ---
#===============================================================================
John Ellinwood
Ugh, looks like the identification section of COBOL program. *shivers*.
ashawley
That looks interesting - will consider that, thanks!(Though the problem with multi-line comments - as in heredoc - remains.)
AnC
+1  A: 

I usually wrap my usage in function so I can call it from a -h param etc.

#!/bin/bash
usage() {
    cat <<EOM
    Usage:
    $(basename $0) Explain options here

EOM
    exit 0
}

[ -z $1 ] && { usage; }
Eddy
I fixed the here doc for you by indenting the script. I don't understand the [ -x $1 ] (if the first argument isn't the path to an executable file, produce usage?); the braces and semicolon around the invocation are redundant too.
Jonathan Leffler
Doh, didn't notice the x; changed it to the z it wanted to be.
Eddy
I guess the braces are habit so I can include an error message along with the check depending on the check. Thanks for the indenting code trick!
Eddy
+5  A: 

Traditionally you document your arguments in the usage() function:

#!/bin/bash

programname=$0

function usage {
    echo "usage: $programname [-abch] [-f infile] [-o outfile]"
    echo " -a  turn on feature a"
    echo " -b  turn on feature b"
    echo " -c  turn on feature c"
    echo " -h  display help"
    echo " -f infile specify input file infile"
    echo " -o outfile specify output file outfile"
    exit 1
}

usage
Chas. Owens
Thanks to everyone for their responses.While they are all fairly Bash-specific, they're useful nevertheless.I'll have to think about how best to implement this (as a common pattern) in Python, Perl, Ruby etc.
AnC
Having thought about this a little more, the in-code documentation is required as well, as it serves a slightly different purpose.So I will adopt the automated usage info, but would still appreciate some advice on the original issue.
AnC