Why these argument parsing errors?

Question

I would like to write a script that requires -c and -f where each requires an option.

When I run my script below I get some unexpected errors:

$ ./user.sh -c
./user.sh: option requires an argument -- c

Usage: user.sh -c username -f filename
   -c username
   -f SSH public key

$ ./user.sh -c gg
Error: You have not given a filename.

In the first case, I would have liked it said I am missing the option for -c and in the second case I would have liked it said I am missing -f.

Question

How do I make such error handing, and what am I doing wrong?

user.sh

#!/bin/bash                                                                                             

usage () {
    echo "Usage: user.sh -c username -f filename"
    echo "   -c username"
    echo "   -f SSH public key"
    echo ""
}

if ! [ "$*"  ]; then
    usage
    exit 1
fi

while getopts "c:f:" opt; do
    case $opt in
        c) user=$OPTARG;;
        f) filename=$OPTARG;;
        \?)
            echo
            usage
            exit 1;;
        *) echo "Internal error: Unknown option.";;
    esac
done

if ! [ $filename ]; then
    echo "Error: You have not given a filename."
    exit 1
fi

if ! [ $user ]; then
    echo "Error: You have not given an username."
    exit 1
fi

Jonathan Leffler · Accepted Answer · 2012-10-31 20:23:01Z

The c: says 'the -c option must be followed by a username'.

The error message says 'the -c option was not followed by a username'.

Granted, it didn't mention 'username' but that's because it doesn't know what it is that follows the option -c.

The getopts built-in cannot handle mandatory options; you have to code that for yourself by checking that the mandatory options were in fact passed. It also doesn't worry if the same option is specified twice; your code has to deal with that if it matters. (It's easy to let the last specified value take effect.)

Modern style is to avoid option letters before mandatory arguments. I'm not wholly in favour of the change; it means that the ordering of the arguments becomes critical in a way that using option letters to indicate what follows does not. Without option letters, you'd write: ./user.sh username filename, but with option letters, you can write either of these and expect it to work:

./user.sh -c username -f filename
./user.sh -f filename -c username

Note that the onus is on you to worry about extra arguments too. You'll typically use:

shift $(($OPTIND - 1))

to remove the processed arguments, and you can then do:

case "$#" in
(0) : No extra arguments - OK;;
(*) echo "$0: Too many arguments" >&2; exit 1;;
esac

And variations on that theme. Note that the error report is sent to standard error, not to standard output — the >&2 redirection sends standard output (file descriptor 1) to standard error (file descriptor 2) instead.

To avoid ambiguity, I'd code your usage function a little differently:

usage()
{
    {
    echo "Usage: user.sh -c username -f filename"
    echo "   -c username    Name of user to connect as"
    echo "   -f filename    SSH public key file"
    echo ""
    } >&2
}

The inner braces do I/O redirection en masse, without starting a subshell. That can be useful when you need to send a number of echo commands to the same place. I've also presented the detail information a little differently, so that a user isn't confused into thinking that 'SSH public key' is three arguments to follow the -f. If there were any pure-option flags, they'd be followed by blanks:

    echo "   -V             Print version information and exit"

Thanks a lot. Do you know of a standard for writing --help output? E.g. how many spaces should I have and denoting mandatory and optional arguments and options?
In the summary line, optional items are in square brackets and mandatory are not: cmd [-ov] -c username -f filename. There's no standard on spaces, beyond 'enough'. In the example, I used 4; that's sufficient; 2 is probably the minimum to give some separation. Otherwise, explore...run various commands with --help and see what they do. Some are longer than others.

Collectives™ on Stack Overflow

Why these argument parsing errors?

1 Answer 1

2 Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Related