There is a difference between command-line arguments and flags. The following diagram clearly specifies the distinction between them:

Suppose that we have a command-line app called storeMarks for saving the marks of a student. It has a flag (called save) to specify whether details should be pushed to DB or not. The arguments that are given are the name and actual marks of the student. We already saw how to collect the flag values in the program. In this section, we will see how to collect program arguments in an expressive way.

For collecting arguments, we use the c.Args function, where c is the cli context of the Action function. Create a directory called cli and add a new program, cli/storeMarks.go:

package main

import (
  "github.com/urfave/cli"
  "log"
  "os"
)

func main() {
  app := cli.NewApp()
  // define flags
  app.Flags = []cli.Flag{
    cli.StringFlag{
      Name:  "save",
      Value: "no",
      Usage: "Should save to database (yes/no)",
    },
  }

  app.Version = "1.0"
  // define action
  app.Action = func(c *cli.Context) error {
    var args []string
    if c.NArg() > 0 {
      // Fetch arguments in a array
      args = c.Args()
      personName := args[0]
      marks := args[1:len(args)]
      log.Println("Person: ", personName)
      log.Println("marks", marks)
    }
    // check the flag value
    if c.String("save") == "no" {
      log.Println("Skipping saving to the database")
    } else {
      // Add database logic here
      log.Println("Saving to the database", args)
    }
    return nil
  }

  app.Run(os.Args)
}

c.Args keeps all of the arguments we entered. Since we know the order of the arguments, we deduced that the first argument is the name and the remaining values are the marks. We are checking a flag called save to save those details in a database or not (we don't have database logic here, for simplicity). app.Version sets the version of the tool. All other things remain the same as the last program.

Let us run this program and see the output:

go build cli/storeMarks.go

Run the program:

./storeMarks --save=yes Albert 89 85 97

2017/09/02 21:02:02 Person: Albert
2017/09/02 21:02:02 marks [89 85 97]
2017/09/02 21:02:02 Saving to the database [Albert 89 85 97]

If we don't give any flag, the default is save=no:

./storeMarks Albert 89 85 97

2017/09/02 21:02:59 Person: Albert
2017/09/02 21:02:59 marks [89 85 97]
2017/09/02 21:02:59 Skipping saving to the database

Everything looks good till now. But how can the tool display help when a user needs it? The cli library already creates a nice help section for the given app. Type any of these commands and help text will be autogenerated:

• ./storeMarks -h (or) 
• ./storeMarks -help (or) 
• ./storeMarks --help 
• ./storeMarks help

A nice help section appears, like this one showing version details and available flags (global options), commands, and arguments:

NAME:
   storeMarks - A new cli application

USAGE:
   storeMarks [global options] command [command options] [arguments...]

VERSION:
   1.0

COMMANDS:
     help, h Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --save value Should save to database (yes/no) (default: "no")
   --help, -h show help
   --version, -v print the version

This actually makes building client applications easier. It is way faster and more intuitive than the internal flag package.