Convert Figma logo to code with AI

alecthomas logokingpin

CONTRIBUTIONS ONLY: A Go (golang) command line and flag parser

3,493
272
3,493
30

Top Related Projects

37,918

A Commander for modern Go CLI interactions

22,275

A simple, fast, and fun package for building command line apps in Go

go command line option parser

1,981

Struct-based argument parsing in Go

A command-line arguments parser that will make you smile.

Quick Overview

Kingpin is a Go (golang) command line and flag parser. It provides a simple and intuitive way to define command-line interfaces for Go applications, supporting both flags and commands with nested subcommands.

Pros

  • Expressive and easy-to-use API for defining complex command-line structures
  • Supports both flags and nested commands
  • Generates comprehensive help text automatically
  • Type-safe flag parsing with support for custom types

Cons

  • May be overkill for very simple command-line applications
  • Learning curve for more advanced features
  • Less suitable for applications requiring dynamic command structures

Code Examples

  1. Basic flag usage:
package main

import (
    "fmt"
    "github.com/alecthomas/kingpin/v2"
)

var (
    verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
    name    = kingpin.Arg("name", "Name to greet.").Required().String()
)

func main() {
    kingpin.Parse()
    if *verbose {
        fmt.Printf("Would greet %s\n", *name)
    }
    fmt.Printf("Hello %s!\n", *name)
}
  1. Defining commands and subcommands:
package main

import (
    "fmt"
    "github.com/alecthomas/kingpin/v2"
)

var (
    app      = kingpin.New("chat", "A chat application.")
    send     = app.Command("send", "Send a message to a user.")
    sendUser = send.Arg("user", "User to send message to.").Required().String()
    sendText = send.Arg("text", "Text message to send.").Required().String()
    list     = app.Command("list", "List all users.")
)

func main() {
    switch kingpin.MustParse(app.Parse(os.Args[1:])) {
    case send.FullCommand():
        fmt.Printf("Sending '%s' to user %s\n", *sendText, *sendUser)
    case list.FullCommand():
        fmt.Println("Listing all users")
    }
}
  1. Custom flag types:
package main

import (
    "fmt"
    "github.com/alecthomas/kingpin/v2"
    "net/url"
)

var (
    urlFlag = kingpin.Flag("url", "URL to parse").Required().URL()
)

func main() {
    kingpin.Parse()
    fmt.Printf("Scheme: %s, Host: %s\n", (*urlFlag).Scheme, (*urlFlag).Host)
}

Getting Started

To use Kingpin in your Go project, first install it:

go get github.com/alecthomas/kingpin/v2

Then, import it in your Go code:

import "github.com/alecthomas/kingpin/v2"

Define your flags and commands at the package level:

var (
    app   = kingpin.New("myapp", "My application description")
    debug = app.Flag("debug", "Enable debug mode").Bool()
    url   = app.Arg("url", "URL to process").Required().URL()
)

func main() {
    kingpin.MustParse(app.Parse(os.Args[1:]))
    // Your application logic here
}

Competitor Comparisons

37,918

A Commander for modern Go CLI interactions

Pros of Cobra

  • More extensive documentation and examples
  • Larger community and ecosystem of plugins
  • Built-in support for generating shell completions

Cons of Cobra

  • More complex API, steeper learning curve
  • Heavier dependency footprint
  • Slower compilation times due to larger codebase

Code Comparison

Kingpin:

var (
    verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
    name    = kingpin.Arg("name", "Name of user.").Required().String()
)

func main() {
    kingpin.Parse()
    // ...
}

Cobra:

var rootCmd = &cobra.Command{
    Use:   "app [name]",
    Short: "A brief description of your application",
    Run: func(cmd *cobra.Command, args []string) {
        // ...
    },
}

func init() {
    rootCmd.Flags().BoolP("verbose", "v", false, "Verbose mode")
    rootCmd.Args = cobra.ExactArgs(1)
}

Both Kingpin and Cobra are popular CLI libraries for Go, offering robust command-line parsing capabilities. Kingpin provides a simpler API and faster compilation, while Cobra offers more features and a larger ecosystem. The choice between them depends on the specific needs of your project, such as complexity, required features, and development speed.

22,275

A simple, fast, and fun package for building command line apps in Go

Pros of cli

  • More actively maintained with frequent updates
  • Supports subcommands and nested subcommands
  • Extensive documentation and examples

Cons of cli

  • More verbose syntax for defining commands and flags
  • Steeper learning curve for complex command structures

Code Comparison

kingpin:

var (
    verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
    name    = kingpin.Arg("name", "Name of user.").Required().String()
)

func main() {
    kingpin.Parse()
    // ...
}

cli:

app := &cli.App{
    Flags: []cli.Flag{
        &cli.BoolFlag{
            Name:    "verbose",
            Aliases: []string{"v"},
            Usage:   "Verbose mode.",
        },
    },
    Action: func(c *cli.Context) error {
        name := c.Args().First()
        // ...
        return nil
    },
}

Summary

Both kingpin and cli are popular Go libraries for building command-line applications. kingpin offers a more concise syntax and easier setup for simple applications, while cli provides more flexibility for complex command structures and subcommands. cli has a larger community and more frequent updates, but may require more code for basic use cases. The choice between the two depends on the specific requirements of your project and personal preference for syntax style.

go command line option parser

Pros of go-flags

  • More flexible command-line syntax, supporting both POSIX and GNU-style options
  • Built-in support for environment variables and configuration files
  • Extensive type support, including custom types and slices

Cons of go-flags

  • Less intuitive API for defining complex command structures
  • Documentation is not as comprehensive as Kingpin's
  • Less active maintenance and fewer recent updates

Code Comparison

go-flags:

type Options struct {
    Verbose []bool `short:"v" long:"verbose" description:"Show verbose debug information"`
    Name    string `short:"n" long:"name" description:"A name" required:"true"`
}

var opts Options
_, err := flags.Parse(&opts)

Kingpin:

var (
    verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
    name    = kingpin.Arg("name", "Name of user.").Required().String()
)

kingpin.Parse()

Both libraries offer command-line parsing capabilities for Go applications, but they differ in their approach and feature set. go-flags provides more flexibility in terms of option syntax and configuration sources, while Kingpin offers a more streamlined API for defining complex command structures. The choice between the two depends on specific project requirements and personal preference.

1,981

Struct-based argument parsing in Go

Pros of go-arg

  • Simpler and more intuitive API, requiring less boilerplate code
  • Automatically generates help text based on struct tags
  • Supports nested structs for organizing complex command-line options

Cons of go-arg

  • Less feature-rich compared to Kingpin (e.g., lacks built-in support for subcommands)
  • Limited customization options for generated help text
  • Smaller community and fewer third-party extensions

Code Comparison

go-arg:

type Args struct {
    Foo string `arg:"required,-f" help:"foo option"`
    Bar int
}

args := Args{}
arg.MustParse(&args)

Kingpin:

var (
    foo = kingpin.Flag("foo", "foo option").Short('f').Required().String()
    bar = kingpin.Flag("bar", "bar option").Int()
)

kingpin.Parse()

Both libraries offer command-line argument parsing for Go applications, but they differ in their approach and feature set. go-arg focuses on simplicity and ease of use, leveraging struct tags for configuration. Kingpin provides a more verbose but highly customizable API with additional features like subcommands and advanced help text formatting. The choice between the two depends on the specific requirements of your project and personal preference for API style.

A command-line arguments parser that will make you smile.

Pros of docopt.go

  • Declarative syntax using a usage string, which can be more intuitive for some developers
  • Automatically generates help messages based on the usage string
  • Supports a wide range of command-line interface patterns out of the box

Cons of docopt.go

  • Less flexibility in defining custom parsing rules
  • May require more verbose usage strings for complex CLI structures
  • Limited built-in support for advanced features like subcommands

Code Comparison

docopt.go:

usage := `Naval Fate.

Usage:
  naval_fate ship new <name>...
  naval_fate ship <name> move <x> <y> [--speed=<kn>]
  naval_fate ship shoot <x> <y>
  naval_fate mine (set|remove) <x> <y> [--moored|--drifting]
  naval_fate -h | --help
  naval_fate --version`

arguments, _ := docopt.Parse(usage, nil, true, "Naval Fate 2.0", false)

kingpin:

var (
  app      = kingpin.New("naval_fate", "A naval fate game.")
  ship     = app.Command("ship", "Ship related commands")
  shipNew  = ship.Command("new", "Create a new ship")
  shipName = shipNew.Arg("name", "Name of ship").Required().String()
)

switch kingpin.MustParse(app.Parse(os.Args[1:])) {
case shipNew.FullCommand():
  // Handle "ship new" command
}

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

CONTRIBUTIONS ONLY

What does this mean? I do not have time to fix issues myself. The only way fixes or new features will be added is by people submitting PRs. If you are interested in taking over maintenance and have a history of contributions to Kingpin, please let me know.

Current status. Kingpin is largely feature stable. There hasn't been a need to add new features in a while, but there are some bugs that should be fixed.

Why? I no longer use Kingpin personally (I now use kong). Rather than leave the project in a limbo of people filing issues and wondering why they're not being worked on, I believe this notice will more clearly set expectations.

Kingpin - A Go (golang) command line and flag parser

CI

Overview

Kingpin is a fluent-style, type-safe command-line parser. It supports flags, nested commands, and positional arguments.

Install it with:

$ go get github.com/alecthomas/kingpin/v2

It looks like this:

var (
  verbose = kingpin.Flag("verbose", "Verbose mode.").Short('v').Bool()
  name    = kingpin.Arg("name", "Name of user.").Required().String()
)

func main() {
  kingpin.Parse()
  fmt.Printf("%v, %s\n", *verbose, *name)
}

More examples are available.

Second to parsing, providing the user with useful help is probably the most important thing a command-line parser does. Kingpin tries to provide detailed contextual help if --help is encountered at any point in the command line (excluding after --).

Features

  • Help output that isn't as ugly as sin.
  • Fully customisable help, via Go templates.
  • Parsed, type-safe flags (kingpin.Flag("f", "help").Int())
  • Parsed, type-safe positional arguments (kingpin.Arg("a", "help").Int()).
  • Parsed, type-safe, arbitrarily deep commands (kingpin.Command("c", "help")).
  • Support for required flags and required positional arguments (kingpin.Flag("f", "").Required().Int()).
  • Support for arbitrarily nested default commands (command.Default()).
  • Callbacks per command, flag and argument (kingpin.Command("c", "").Action(myAction)).
  • POSIX-style short flag combining (-a -b -> -ab).
  • Short-flag+parameter combining (-a parm -> -aparm).
  • Read command-line from files (@<file>).
  • Automatically generate man pages (--help-man).

User-visible changes between v1 and v2

Flags can be used at any point after their definition.

Flags can be specified at any point after their definition, not just immediately after their associated command. From the chat example below, the following used to be required:

$ chat --server=chat.server.com:8080 post --image=~/Downloads/owls.jpg pics

But the following will now work:

$ chat post --server=chat.server.com:8080 --image=~/Downloads/owls.jpg pics

Short flags can be combined with their parameters

Previously, if a short flag was used, any argument to that flag would have to be separated by a space. That is no longer the case.

API changes between v1 and v2

  • ParseWithFileExpansion() is gone. The new parser directly supports expanding @<file>.
  • Added FatalUsage() and FatalUsageContext() for displaying an error + usage and terminating.
  • Dispatch() renamed to Action().
  • Added ParseContext() for parsing a command line into its intermediate context form without executing.
  • Added Terminate() function to override the termination function.
  • Added UsageForContextWithTemplate() for printing usage via a custom template.
  • Added UsageTemplate() for overriding the default template to use. Two templates are included:
    1. DefaultUsageTemplate - default template.
    2. CompactUsageTemplate - compact command template for larger applications.

Versions

The current stable version is github.com/alecthomas/kingpin/v2. The previous version, gopkg.in/alecthomas/kingpin.v1, is deprecated and in maintenance mode.

V2 is the current stable version

Installation:

$ go get github.com/alecthomas/kingpin/v2

V1 is the OLD stable version

Installation:

$ go get gopkg.in/alecthomas/kingpin.v1

Change History

  • 2015-09-19 -- Stable v2.1.0 release.

    • Added command.Default() to specify a default command to use if no other command matches. This allows for convenient user shortcuts.
    • Exposed HelpFlag and VersionFlag for further customisation.
    • Action() and PreAction() added and both now support an arbitrary number of callbacks.
    • kingpin.SeparateOptionalFlagsUsageTemplate.
    • --help-long and --help-man (hidden by default) flags.
    • Flags are "interspersed" by default, but can be disabled with app.Interspersed(false).
    • Added flags for all simple builtin types (int8, uint16, etc.) and slice variants.
    • Use app.Writer(os.Writer) to specify the default writer for all output functions.
    • Dropped os.Writer prefix from all printf-like functions.
  • 2015-05-22 -- Stable v2.0.0 release.

    • Initial stable release of v2.0.0.
    • Fully supports interspersed flags, commands and arguments.
    • Flags can be present at any point after their logical definition.
    • Application.Parse() terminates if commands are present and a command is not parsed.
    • Dispatch() -> Action().
    • Actions are dispatched after all values are populated.
    • Override termination function (defaults to os.Exit).
    • Override output stream (defaults to os.Stderr).
    • Templatised usage help, with default and compact templates.
    • Make error/usage functions more consistent.
    • Support argument expansion from files by default (with @).
    • Fully public data model is available via .Model().
    • Parser has been completely refactored.
    • Parsing and execution has been split into distinct stages.
    • Use go generate to generate repeated flags.
    • Support combined short-flag+argument: -fARG.
  • 2015-01-23 -- Stable v1.3.4 release.

    • Support "--" for separating flags from positional arguments.
    • Support loading flags from files (ParseWithFileExpansion()). Use @FILE as an argument.
    • Add post-app and post-cmd validation hooks. This allows arbitrary validation to be added.
    • A bunch of improvements to help usage and formatting.
    • Support arbitrarily nested sub-commands.
  • 2014-07-08 -- Stable v1.2.0 release.

    • Pass any value through to Strings() when final argument. Allows for values that look like flags to be processed.
    • Allow --help to be used with commands.
    • Support Hidden() flags.
    • Parser for units.Base2Bytes type. Allows for flags like --ram=512MB or --ram=1GB.
    • Add an Enum() value, allowing only one of a set of values to be selected. eg. Flag(...).Enum("debug", "info", "warning").
  • 2014-06-27 -- Stable v1.1.0 release.

    • Bug fixes.
    • Always return an error (rather than panicing) when misconfigured.
    • OpenFile(flag, perm) value type added, for finer control over opening files.
    • Significantly improved usage formatting.
  • 2014-06-19 -- Stable v1.0.0 release.

    • Support cumulative positional arguments.
    • Return error rather than panic when there are fatal errors not caught by the type system. eg. when a default value is invalid.
    • Use gokpg.in.
  • 2014-06-10 -- Place-holder streamlining.

    • Renamed MetaVar to PlaceHolder.
    • Removed MetaVarFromDefault. Kingpin now uses heuristics to determine what to display.

Examples

Simple Example

Kingpin can be used for simple flag+arg applications like so:

$ ping --help
usage: ping [<flags>] <ip> [<count>]

Flags:
  --debug            Enable debug mode.
  --help             Show help.
  -t, --timeout=5s   Timeout waiting for ping.

Args:
  <ip>        IP address to ping.
  [<count>]   Number of packets to send
$ ping 1.2.3.4 5
Would ping: 1.2.3.4 with timeout 5s and count 5

From the following source:

package main

import (
  "fmt"

  "github.com/alecthomas/kingpin/v2"
)

var (
  debug   = kingpin.Flag("debug", "Enable debug mode.").Bool()
  timeout = kingpin.Flag("timeout", "Timeout waiting for ping.").Default("5s").Envar("PING_TIMEOUT").Short('t').Duration()
  ip      = kingpin.Arg("ip", "IP address to ping.").Required().IP()
  count   = kingpin.Arg("count", "Number of packets to send").Int()
)

func main() {
  kingpin.Version("0.0.1")
  kingpin.Parse()
  fmt.Printf("Would ping: %s with timeout %s and count %d\n", *ip, *timeout, *count)
}

Reading arguments from a file

Kingpin supports reading arguments from a file. Create a file with the corresponding arguments:

echo -t=5\n > args

And now supply it:

$ ping @args

Complex Example

Kingpin can also produce complex command-line applications with global flags, subcommands, and per-subcommand flags, like this:

$ chat --help
usage: chat [<flags>] <command> [<flags>] [<args> ...]

A command-line chat application.

Flags:
  --help              Show help.
  --debug             Enable debug mode.
  --server=127.0.0.1  Server address.

Commands:
  help [<command>]
    Show help for a command.

  register <nick> <name>
    Register a new user.

  post [<flags>] <channel> [<text>]
    Post a message to a channel.

$ chat help post
usage: chat [<flags>] post [<flags>] <channel> [<text>]

Post a message to a channel.

Flags:
  --image=IMAGE  Image to post.

Args:
  <channel>  Channel to post to.
  [<text>]   Text to post.

$ chat post --image=~/Downloads/owls.jpg pics
...

From this code:

package main

import (
  "os"
  "strings"
  "github.com/alecthomas/kingpin/v2"
)

var (
  app      = kingpin.New("chat", "A command-line chat application.")
  debug    = app.Flag("debug", "Enable debug mode.").Bool()
  serverIP = app.Flag("server", "Server address.").Default("127.0.0.1").IP()

  register     = app.Command("register", "Register a new user.")
  registerNick = register.Arg("nick", "Nickname for user.").Required().String()
  registerName = register.Arg("name", "Name of user.").Required().String()

  post        = app.Command("post", "Post a message to a channel.")
  postImage   = post.Flag("image", "Image to post.").File()
  postChannel = post.Arg("channel", "Channel to post to.").Required().String()
  postText    = post.Arg("text", "Text to post.").Strings()
)

func main() {
  switch kingpin.MustParse(app.Parse(os.Args[1:])) {
  // Register user
  case register.FullCommand():
    println(*registerNick)

  // Post message
  case post.FullCommand():
    if *postImage != nil {
    }
    text := strings.Join(*postText, " ")
    println("Post:", text)
  }
}

Reference Documentation

Displaying errors and usage information

Kingpin exports a set of functions to provide consistent errors and usage information to the user.

Error messages look something like this:

<app>: error: <message>

The functions on Application are:

FunctionPurpose
Errorf(format, args)Display a printf formatted error to the user.
Fatalf(format, args)As with Errorf, but also call the termination handler.
FatalUsage(format, args)As with Fatalf, but also print contextual usage information.
FatalUsageContext(context, format, args)As with Fatalf, but also print contextual usage information from a ParseContext.
FatalIfError(err, format, args)Conditionally print an error prefixed with format+args, then call the termination handler

There are equivalent global functions in the kingpin namespace for the default kingpin.CommandLine instance.

Sub-commands

Kingpin supports nested sub-commands, with separate flag and positional arguments per sub-command. Note that positional arguments may only occur after sub-commands.

For example:

var (
  deleteCommand     = kingpin.Command("delete", "Delete an object.")
  deleteUserCommand = deleteCommand.Command("user", "Delete a user.")
  deleteUserUIDFlag = deleteUserCommand.Flag("uid", "Delete user by UID rather than username.")
  deleteUserUsername = deleteUserCommand.Arg("username", "Username to delete.")
  deletePostCommand = deleteCommand.Command("post", "Delete a post.")
)

func main() {
  switch kingpin.Parse() {
  case deleteUserCommand.FullCommand():
  case deletePostCommand.FullCommand():
  }
}

Custom Parsers

Kingpin supports both flag and positional argument parsers for converting to Go types. For example, some included parsers are Int(), Float(), Duration() and ExistingFile() (see parsers.go for a complete list of included parsers).

Parsers conform to Go's flag.Value interface, so any existing implementations will work.

For example, a parser for accumulating HTTP header values might look like this:

type HTTPHeaderValue http.Header

func (h *HTTPHeaderValue) Set(value string) error {
  parts := strings.SplitN(value, ":", 2)
  if len(parts) != 2 {
    return fmt.Errorf("expected HEADER:VALUE got '%s'", value)
  }
  (*http.Header)(h).Add(parts[0], parts[1])
  return nil
}

func (h *HTTPHeaderValue) String() string {
  return ""
}

As a convenience, I would recommend something like this:

func HTTPHeader(s Settings) (target *http.Header) {
  target = &http.Header{}
  s.SetValue((*HTTPHeaderValue)(target))
  return
}

You would use it like so:

headers = HTTPHeader(kingpin.Flag("header", "Add a HTTP header to the request.").Short('H'))

Repeatable flags

Depending on the Value they hold, some flags may be repeated. The IsCumulative() bool function on Value tells if it's safe to call Set() multiple times or if an error should be raised if several values are passed.

The built-in Values returning slices and maps, as well as Counter are examples of Values that make a flag repeatable.

Boolean values

Boolean values are uniquely managed by Kingpin. Each boolean flag will have a negative complement: --<name> and --no-<name>.

Default Values

The default value is the zero value for a type. This can be overridden with the Default(value...) function on flags and arguments. This function accepts one or several strings, which are parsed by the value itself, so they must be compliant with the format expected.

Place-holders in Help

The place-holder value for a flag is the value used in the help to describe the value of a non-boolean flag.

The value provided to PlaceHolder() is used if provided, then the value provided by Default() if provided, then finally the capitalised flag name is used.

Here are some examples of flags with various permutations:

--name=NAME           // Flag(...).String()
--name="Harry"        // Flag(...).Default("Harry").String()
--name=FULL-NAME      // Flag(...).PlaceHolder("FULL-NAME").Default("Harry").String()

Consuming all remaining arguments

A common command-line idiom is to use all remaining arguments for some purpose. eg. The following command accepts an arbitrary number of IP addresses as positional arguments:

./cmd ping 10.1.1.1 192.168.1.1

Such arguments are similar to repeatable flags, but for arguments. Therefore they use the same IsCumulative() bool function on the underlying Value, so the built-in Values for which the Set() function can be called several times will consume multiple arguments.

To implement the above example with a custom Value, we might do something like this:

type ipList []net.IP

func (i *ipList) Set(value string) error {
  if ip := net.ParseIP(value); ip == nil {
    return fmt.Errorf("'%s' is not an IP address", value)
  } else {
    *i = append(*i, ip)
    return nil
  }
}

func (i *ipList) String() string {
  return ""
}

func (i *ipList) IsCumulative() bool {
  return true
}

func IPList(s Settings) (target *[]net.IP) {
  target = new([]net.IP)
  s.SetValue((*ipList)(target))
  return
}

And use it like so:

ips := IPList(kingpin.Arg("ips", "IP addresses to ping."))

Bash/ZSH Shell Completion

By default, all flags and commands/subcommands generate completions internally.

Out of the box, CLI tools using kingpin should be able to take advantage of completion hinting for flags and commands. By specifying --completion-bash as the first argument, your CLI tool will show possible subcommands. By ending your argv with --, hints for flags will be shown.

To allow your end users to take advantage you must package a /etc/bash_completion.d script with your distribution (or the equivalent for your target platform/shell). An alternative is to instruct your end user to source a script from their bash_profile (or equivalent).

Fortunately Kingpin makes it easy to generate or source a script for use with end users shells. ./yourtool --completion-script-bash and ./yourtool --completion-script-zsh will generate these scripts for you.

Installation by Package

For the best user experience, you should bundle your pre-created completion script with your CLI tool and install it inside /etc/bash_completion.d (or equivalent). A good suggestion is to add this as an automated step to your build pipeline, in the implementation is improved for bug fixed.

Installation by bash_profile

Alternatively, instruct your users to add an additional statement to their bash_profile (or equivalent):

eval "$(your-cli-tool --completion-script-bash)"

Or for ZSH

eval "$(your-cli-tool --completion-script-zsh)"

Additional API

To provide more flexibility, a completion option API has been exposed for flags to allow user defined completion options, to extend completions further than just EnumVar/Enum.

Provide Static Options

When using an Enum or EnumVar, users are limited to only the options given. Maybe we wish to hint possible options to the user, but also allow them to provide their own custom option. HintOptions gives this functionality to flags.

app := kingpin.New("completion", "My application with bash completion.")
app.Flag("port", "Provide a port to connect to").
    Required().
    HintOptions("80", "443", "8080").
    IntVar(&c.port)

Provide Dynamic Options Consider the case that you needed to read a local database or a file to provide suggestions. You can dynamically generate the options

func listHosts() []string {
  // Provide a dynamic list of hosts from a hosts file or otherwise
  // for bash completion. In this example we simply return static slice.

  // You could use this functionality to reach into a hosts file to provide
  // completion for a list of known hosts.
  return []string{"sshhost.example", "webhost.example", "ftphost.example"}
}

app := kingpin.New("completion", "My application with bash completion.")
app.Flag("flag-1", "").HintAction(listHosts).String()

EnumVar/Enum When using Enum or EnumVar, any provided options will be automatically used for bash autocompletion. However, if you wish to provide a subset or different options, you can use HintOptions or HintAction which will override the default completion options for Enum/EnumVar.

Examples You can see an in depth example of the completion API within examples/completion/main.go

Supporting -h for help

kingpin.CommandLine.HelpFlag.Short('h')

Short help is also available when creating a more complicated app:

var (
	app = kingpin.New("chat", "A command-line chat application.")
  // ...
)

func main() {
	app.HelpFlag.Short('h')
	switch kingpin.MustParse(app.Parse(os.Args[1:])) {
  // ...
  }
}

Custom help

Kingpin v2 supports templatised help using the text/template library (actually, a fork).

You can specify the template to use with the Application.UsageTemplate() function.

There are four included templates: kingpin.DefaultUsageTemplate is the default, kingpin.CompactUsageTemplate provides a more compact representation for more complex command-line structures, kingpin.SeparateOptionalFlagsUsageTemplate looks like the default template, but splits required and optional command flags into separate lists, and kingpin.ManPageTemplate is used to generate man pages.

See the above templates for examples of usage, and the the function UsageForContextWithTemplate() method for details on the context.

Default help template

$ go run ./examples/curl/curl.go --help
usage: curl [<flags>] <command> [<args> ...]

An example implementation of curl.

Flags:
  --help            Show help.
  -t, --timeout=5s  Set connection timeout.
  -H, --headers=HEADER=VALUE
                    Add HTTP headers to the request.

Commands:
  help [<command>...]
    Show help.

  get url <url>
    Retrieve a URL.

  get file <file>
    Retrieve a file.

  post [<flags>] <url>
    POST a resource.

Compact help template

$ go run ./examples/curl/curl.go --help
usage: curl [<flags>] <command> [<args> ...]

An example implementation of curl.

Flags:
  --help            Show help.
  -t, --timeout=5s  Set connection timeout.
  -H, --headers=HEADER=VALUE
                    Add HTTP headers to the request.

Commands:
  help [<command>...]
  get [<flags>]
    url <url>
    file <file>
  post [<flags>] <url>