gistfile1.sh

while getopts ":a:o:" opt; do
  case $opt in
    a)
      echo "Getting ready to set environment variables for $2"

      echo "Setting CANONICAL_URL"
      heroku config:set CANONICAL_URL=$2.herokuapp.com --app $2

      echo "Setting DOMAIN_NAME"
      heroku config:set DOMAIN_NAME=herokuapp.com --app $2

      echo "Setting SECRET_TOKEN"
      token2=$(cat /dev/random | LC_CTYPE=C tr -dc "[:alnum:]" | head -c 128)
      heroku config:set SECRET_TOKEN=$token2 --app $2

      echo "Getting ready to install add-ons for $2"

      echo "Installing Mandrill by MailChimp"
      heroku addons:add mandrill --app $2

      echo "Installing Memcachier"
      heroku addons:add memcachier --app $2

      echo "Installing New Relic"
      heroku addons:add newrelic --app $2
      ;;
    o)
      echo "Setting OHANA_API_ENDPOINT"
      heroku config:set OHANA_API_ENDPOINT=$4 --app $2
      ;;
    \?)
      echo "Invalid option: -$OPTARG" >&2
      echo "Usage: setup_heroku -a your_app_name -o your_api_endpoint" >&2
      exit 1
      ;;
    :)
      echo "Option -$OPTARG requires an argument" >&2
      echo "Usage: setup_heroku -a your_app_name -o your_api_endpoint" >&2
      exit 1
      ;;
  esac
done

@ycombinator, good point about the positional parameters, but how would I deal with the possibility that they supplied the parameters in the wrong order? I guess Heroku would throw an error because it wouldn't find an app by the name of the endpoint.

Exactly, your script is a client-side interface. You could keep it relatively dumb and let the server-side (in this case, Heroku) handle validation. Or you could be nicer to your users and keep the validation closer to them, in the script itself. The other benefit of the latter approach (client-side validation) is that it is better for transactional operations - that is, you don't want to do partial work on the server, then run into a validation error from the server and have to undo a bunch of work.

So, for instance, you could check that the API endpoint parameter value matched the regex /^https?:/// before passing it off to Heroku.

Also, if you think about it, all this validation logic has nothing to do with whether the parameters are positional or optional. Either way, you could run into the same problems with a user specifying the wrong one in the wrong place.