An example from the kubernetes project, for the `kubectl config`
command, which as subcommands, and flags, and all sorts of stuff, it
will generate markdown like so:
config modifies .kubeconfig files
config modifies .kubeconfig files using subcommands like "kubectl config set current-context my-context"
```
kubectl config SUBCOMMAND
```
```
--envvar=false: use the .kubeconfig from $KUBECONFIG
--global=false: use the .kubeconfig from /home/username
-h, --help=false: help for config
--kubeconfig="": use a particular .kubeconfig file
--local=false: use the .kubeconfig in the current directory
```
```
--alsologtostderr=false: log to standard error as well as files
--api-version="": The API version to use when talking to the server
-a, --auth-path="": Path to the auth info file. If missing, prompt the user. Only used if using https.
--certificate-authority="": Path to a cert. file for the certificate authority.
--client-certificate="": Path to a client key file for TLS.
--client-key="": Path to a client key file for TLS.
--cluster="": The name of the kubeconfig cluster to use
--context="": The name of the kubeconfig context to use
--insecure-skip-tls-verify=false: If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure.
--log_backtrace_at=:0: when logging hits line file:N, emit a stack trace
--log_dir=: If non-empty, write log files in this directory
--log_flush_frequency=5s: Maximum number of seconds between log flushes
--logtostderr=true: log to standard error instead of files
--match-server-version=false: Require server version to match client version
--namespace="": If present, the namespace scope for this CLI request.
--password="": Password for basic authentication to the API server.
-s, --server="": The address and port of the Kubernetes API server
--stderrthreshold=2: logs at or above this threshold go to stderr
--token="": Bearer token for authentication to the API server.
--user="": The name of the kubeconfig user to use
--username="": Username for basic authentication to the API server.
--v=0: log level for V logs
--validate=false: If true, use a schema to validate the input before sending it
--vmodule=: comma-separated list of pattern=N settings for file-filtered logging
```
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
* [kubectl config set](kubectl_config_set.md) - Sets an individual value in a .kubeconfig file
* [kubectl config set-cluster](kubectl_config_set-cluster.md) - Sets a cluster entry in .kubeconfig
* [kubectl config set-context](kubectl_config_set-context.md) - Sets a context entry in .kubeconfig
* [kubectl config set-credentials](kubectl_config_set-credentials.md) - Sets a user entry in .kubeconfig
* [kubectl config unset](kubectl_config_unset.md) - Unsets an individual value in a .kubeconfig file
* [kubectl config use-context](kubectl_config_use-context.md) - Sets the current-context in a .kubeconfig file
* [kubectl config view](kubectl_config_view.md) - displays merged .kubeconfig settings or a specified .kubeconfig file.
We had some stuff that created a new empty []string if args was already
and empty string (why?)
We had some stuff that called Help() if it wasn't runnable (but
.execute() already does that)
Just remove the special case stuff.
The special case code to handle a runnable root command had some
problems. It was noticed that if you created a runnable root and a
subcommand. And the subcommand was then executed with both a valid and
invalid flag, the error message was about the valid flag being invalid.
For example
./command subcommand --goodflag=10 --badflag=10
Would fail and tell you that --goodflag was an invalid flag. Instead if
we just do away with the special Command.execute() for the root command
the parser for subcommand is what prints the error and it gets it
right...
The additional help topics were really hard to ever get to show. The
required conditionals were difficult to meet and did not seem to really
be logical.
Problems I see:
1) the top level command could never have additional topics.
2) you must have at least one sibling command AND one subcommand
3) we had the AND above, but then test both conditionals a second time
4) if the sub command was runnable we wouldn't print anything
5) if the sibling commands were not runnable we wouldn't print anything
4+5) it's possible that we printed "Additional help topics:" with nothing following it
6) We always printed ourselves as a sibling in the additional info
Whew, I think I fixed all of those! Again, using
https://github.com/eparis/readable-golang-template
I'm actually able to visualize the template and see this craziness.
The conditionals BEFORE this change:
{{if .HasParent}}
{{if and (gt .Commands 0) (gt .Parent.Commands 1) }}
Additional help topics:
{{if gt .Commands 0 }}
{{range .Commands}}
{{if not .Runnable}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{if gt .Parent.Commands 1 }}
{{range .Parent.Commands}}
{{if .Runnable}}
{{if not (eq .Name $cmd.Name) }}
{{end}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{end}}
{{end}}
The conditionals AFTER this change:
{{if or (.HasHelpSubCommands) (.HasRunnableSiblings)}}
Additional help topics:
{{if .HasHelpSubCommands}}
{{range .Commands}}
{{if not .Runnable}}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{if .HasRunnableSiblings }}
{{range .Parent.Commands}}
{{if .Runnable}}
{{if not (eq .Name $cmd.Name) }}
{{rpad .CommandPath .CommandPathPadding}} {{.Short}}
{{end}}
{{end}}
{{end}}
{{end}}
{{end}}
