flags.go 6.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141
  1. // Copyright 2012 Jesse van den Kieboom. All rights reserved.
  2. // Use of this source code is governed by a BSD-style
  3. // license that can be found in the LICENSE file.
  4. // Package flags provides an extensive command line option parser.
  5. // The flags package is similar in functionality to the go builtin flag package
  6. // but provides more options and uses reflection to provide a convenient and
  7. // succinct way of specifying command line options.
  8. //
  9. // Supported features:
  10. // Options with short names (-v)
  11. // Options with long names (--verbose)
  12. // Options with and without arguments (bool v.s. other type)
  13. // Options with optional arguments and default values
  14. // Multiple option groups each containing a set of options
  15. // Generate and print well-formatted help message
  16. // Passing remaining command line arguments after -- (optional)
  17. // Ignoring unknown command line options (optional)
  18. // Supports -I/usr/include -I=/usr/include -I /usr/include option argument specification
  19. // Supports multiple short options -aux
  20. // Supports all primitive go types (string, int{8..64}, uint{8..64}, float)
  21. // Supports same option multiple times (can store in slice or last option counts)
  22. // Supports maps
  23. // Supports function callbacks
  24. //
  25. // Additional features specific to Windows:
  26. // Options with short names (/v)
  27. // Options with long names (/verbose)
  28. // Windows-style options with arguments use a colon as the delimiter
  29. // Modify generated help message with Windows-style / options
  30. //
  31. // The flags package uses structs, reflection and struct field tags
  32. // to allow users to specify command line options. This results in very simple
  33. // and consise specification of your application options. For example:
  34. //
  35. // type Options struct {
  36. // Verbose []bool `short:"v" long:"verbose" description:"Show verbose debug information"`
  37. // }
  38. //
  39. // This specifies one option with a short name -v and a long name --verbose.
  40. // When either -v or --verbose is found on the command line, a 'true' value
  41. // will be appended to the Verbose field. e.g. when specifying -vvv, the
  42. // resulting value of Verbose will be {[true, true, true]}.
  43. //
  44. // Slice options work exactly the same as primitive type options, except that
  45. // whenever the option is encountered, a value is appended to the slice.
  46. //
  47. // Map options from string to primitive type are also supported. On the command
  48. // line, you specify the value for such an option as key:value. For example
  49. //
  50. // type Options struct {
  51. // AuthorInfo string[string] `short:"a"`
  52. // }
  53. //
  54. // Then, the AuthorInfo map can be filled with something like
  55. // -a name:Jesse -a "surname:van den Kieboom".
  56. //
  57. // Finally, for full control over the conversion between command line argument
  58. // values and options, user defined types can choose to implement the Marshaler
  59. // and Unmarshaler interfaces.
  60. //
  61. // Available field tags:
  62. // short: the short name of the option (single character)
  63. // long: the long name of the option
  64. // description: the description of the option (optional)
  65. // optional: whether an argument of the option is optional (optional)
  66. // optional-value: the value of an optional option when the option occurs
  67. // without an argument. This tag can be specified multiple
  68. // times in the case of maps or slices (optional)
  69. // default: the default value of an option. This tag can be specified
  70. // multiple times in the case of slices or maps (optional).
  71. // default-mask: when specified, this value will be displayed in the help
  72. // instead of the actual default value. This is useful
  73. // mostly for hiding otherwise sensitive information from
  74. // showing up in the help. If default-mask takes the special
  75. // value "-", then no default value will be shown at all
  76. // (optional)
  77. // required: whether an option is required to appear on the command
  78. // line. If a required option is not present, the parser
  79. // will return ErrRequired.
  80. // base: a base (radix) used to convert strings to integer values,
  81. // the default base is 10 (i.e. decimal) (optional)
  82. // value-name: the name of the argument value (to be shown in the help,
  83. // (optional)
  84. // group: when specified on a struct field, makes the struct field
  85. // a separate group with the given name (optional).
  86. // command: when specified on a struct field, makes the struct field
  87. // a (sub)command with the given name (optional).
  88. //
  89. // Either short: or long: must be specified to make the field eligible as an
  90. // option.
  91. //
  92. //
  93. // Option groups:
  94. //
  95. // Option groups are a simple way to semantically separate your options. The
  96. // only real difference is in how your options will appear in the builtin
  97. // generated help. All options in a particular group are shown together in the
  98. // help under the name of the group.
  99. //
  100. // There are currently three ways to specify option groups.
  101. //
  102. // 1. Use NewNamedParser specifying the various option groups.
  103. // 2. Use AddGroup to add a group to an existing parser.
  104. // 3. Add a struct field to the toplevel options annotated with the
  105. // group:"group-name" tag.
  106. //
  107. //
  108. //
  109. // Commands:
  110. //
  111. // The flags package also has basic support for commands. Commands are often
  112. // used in monolithic applications that support various commands or actions.
  113. // Take git for example, all of the add, commit, checkout, etc. are called
  114. // commands. Using commands you can easily separate multiple functions of your
  115. // application.
  116. //
  117. // There are currently two ways to specifiy a command.
  118. //
  119. // 1. Use AddCommand on an existing parser.
  120. // 2. Add a struct field to your options struct annotated with the
  121. // command:"command-name" tag.
  122. //
  123. // The most common, idiomatic way to implement commands is to define a global
  124. // parser instance and implement each command in a separate file. These
  125. // command files should define a go init function which calls AddCommand on
  126. // the global parser.
  127. //
  128. // When parsing ends and there is an active command and that command implements
  129. // the Commander interface, then its Execute method will be run with the
  130. // remaining command line arguments.
  131. //
  132. // Command structs can have options which become valid to parse after the
  133. // command has been specified on the command line. It is currently not valid
  134. // to specify options from the parent level of the command after the command
  135. // name has occurred. Thus, given a toplevel option "-v" and a command "add":
  136. //
  137. // Valid: ./app -v add
  138. // Invalid: ./app add -v
  139. //
  140. package flags