[mey]

Handling of arguments is one of the reasons I reach for Python or Powershell instead of a bash script when writing my own stuff.

https://docs.python.org/3/library/argparse.html is great.

Powershell has the Param keyword that functions like argparse in Python

https://docs.microsoft.com/en-us/powershell/module/microsoft...

[Spivak]

But handling args isn't that bad in bash.

    while [[ $# -gt 0 ]]; do
      case "$1" in
         -h|--help)
           do_help
           exit
           ;;
         -v|--version)
           do_version
           exit
           ;;
         -d|--debug)
           debug=true
           shift
           ;;
         -a|--arg)
           arg_value=$2
           shift 2
           ;;
      esac
    done

[mey]

    import argparse
    parser = argparse.ArgumentParser()
    parser.add_argument('-v','--version',action='version', version='demo',help='Print version information')
    parser.add_argument('-d','--debug', help='Enable Debug Mode')
    parser.add_argument('a','arg', help="Argument Documentation")
    args = parser.parse_args()

Personally I feel like this is more readable code, gets me better validation, and help docs for "free". That's the attraction.

[gitgud]

Elegant, but then it's no longer a basic shell-script as it requires python installed.

If you can live with additional dependencies, then I like the node [1] commander package, which is very readable and nice to work with in my opinion.

        #!/usr/bin/env node
        const { program } = require('commander');

        program
          .command('clone <source> [destination]')
          .description('clone a repository')
          .action((source, destination) => {
            console.log('clone command called');
          });

It also automatically generates the --help output for ./script -h

[1] https://github.com/tj/commander.js/

[jolmg]

To expand on that pattern:

    while (( $# )); do
      case "$1" in
        -h|--help)
          usage
          exit
          ;;

        -v|--version)
          do_version
          exit
          ;;

        -d|--debug)
          debug=true
          ;;

        -a|--arg)
          arg_value="$2"
          shift
          ;;

        *)
          if [[ ! -v pos1 ]]; then
            pos1="$1"
          elif [[ ! -v pos2 ]]; then
            pos2="$1"
          else
            >&2 printf "%s: unrecognized argument\n" "$1"
            >&2 usage
            exit 1
          fi
      esac

      shift
    done

[bewuethr]

The one downside of this is that it doesn't handle squeezing flags as in

    foo -da bar

whereas getopts does. On the other hand, with (the Bash built-in) getopts you're limited to single character flags.

[Spivak]

You can do that it will just make things a little less pretty.

    while (( $# )); do
        case "$1" in
            -*h*|--help)
                do_help
                exit
                ;;
            -*v*|--version)
                do_version
                exit
                ;;
            -*d*|--debug)
                debug=true
                ;;&
            -*a*|--arg)
                value="$2"
                shift
                ;;&
        esac
        shift
    done

It doesn't support args of the form -avalue but those a pretty uncommon anyway.

[jolmg]

That wouldn't work in the general case. Those patterns would also match long options. If I add a case pattern `--all)`, and I call the script with `--all`, it's also going to match

  -*a*|--arg)

You could fix that with:

  -a*|-[!-]*a*|--arg)

> It doesn't support args of the form -avalue but those a pretty uncommon anyway.

You could

  -a*|-[!-]*a*|--arg)
    if [[ "$1" != --arg ]]; then
      value="${1#*a}"
    fi
    if [[ ! "$value" ]]; then
      value="$2"
      shift
    fi
  ;;&

Putting the option stuck together to its value has the advantage of working nicely with brace expansion. For example, you can call `strace -p{1111,2222,3333}` to trace those 3 pids and avoid having to type `-p` 3 times.

[jolmg]

As a final addendum, case clauses of options that take arguments like -a/--arg should not be terminated with `;;&`, but rather with `;;`.

[dragonwriter]

> https://docs.python.org/3/library/argparse.html is great

Argparse is okay (and being in stdlib makes it always-available), but it's no click. https://click.palletsprojects.com/en/7.x/

[mey]

This is why I love the HN community, learning something new every day. (Happy 10,000) I use argparse because it is stdlib, but will checkout click!

[40four]

Thumbs up for 'Click'. I used it for a project once, and I was really happy with it. Easy to use, good docs. Would use it again.

[gavinray]

Googling the library appears to be about ~8,000 lines of code (core.py is ~2,000 alone).

Is that really reasonable sounding to most people for parsing CLI input/output and display manpages or helptext?

[dastx]

I suppose it depends on the use case. Personally I've always thought argparse is good enough, and have never hit a roadblock "because I'm using argparse" so to say. Having said that, I do like the pattern click is going for. If it argparse allowed the same pattern, in my opinion that would be cool, and it would probably be my first choice.

[blondin]

argparse should not be the first thing to reach for, imo, when good old sys.argv can do the job.

[mey]

At that point I wouldn't leave bash. I feel like argparse allows for better documentation, error handling and input validation.

[40four]

I didn’t mean to suggest we should reach for Click for simple help/manpage display.

The case I used it for was much more complex. What I liked about it was the easy to use API, clear documentation & examples, and readable patterns.

For simple text display, I like the solution from the article, and I learned something new about bash scripts. Also, I learned from comments you can use heredoc in bash!

[meddlepal]

I'm not trying to be antagonistic here... but who cares how many lines it has unless you plan to maintain it?

[pletnes]

It’s fantastic and should be used by most CLI programs. Argparse is much faster and avoids having a dependency, so it does serve a purpose.

[wahern]

The original argparse is available in every Unix shell: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g...

[nickysielicki]

See also: https://github.com/nhoffman/argparse-bash

A great option when you're stuck with an old crusty script that you don't want to completely rewrite in python, but do want to clean up enough so that you can call it with `-h` and remember how to use it a few months in the future.

Unfortunately, this won't help you if you're on embedded where python isn't in the base system.

[sidpatil]

PowerShell also has comment-based help, which is like a manpage embedded as a comment within the script. It's like OP's suggested help format, but better.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

[hnarn]

I also really like the "flag" package for Go, it generates the help text for you and easily lets you set defaults as well as helps you type-check inputs.

[PenguinCoder]

I like https://github.com/jpillora/opts for Go arg parsing. It has better, sane defaults with long/short opts.

[hnarn]

Cool, I'll check it out. There's something attractive about using stuff from the standard library though.

[acdha]

My rule for a long time has been that any time you have more than one screen's worth of code and/or are using any of arrays, functions, or more than simple positional arguments you'll save time by rewriting it in Python. shellcheck has helped soften that a bit but the usability difference is pretty noticeable even with multiple decades writing shell scripts.

[daitangio]

Try pyhon click: from flask& jinja2 author, it is very nice