This makes sorting flags and other sections consistent with how most
command line tools function, by placing both flags `-A` and `-a` before
a flag `-B`.
This will allow users to customize the prefix section or env hint
section of the flag entries in the help menu without having to
reimplement the rest of the logic required in defining FlagStringer.
Users can now use custom flags types (conforming to the Flag interface)
in their applications. They can also use custom flags for the three
global flags (Help, Version, bash completion).
Currently cli silently (aside from IntSlice and Int64Slice which oddly
printed directly to the error stream) ignores failures that occur when
parsing environment variables for their value for flags that define
environment variables. Instead, we should propogate up the error to the
user.
This is accomplished in a backwards compatible manner by adding a new,
internal, interface which defines an applyWithError function that all
flags here define. In v2, when we can modify the interface, we can drop
this secondary interface and modify `Apply` to return an error.
When assigning values to flags (also when interogatting via
`context.(Global)IsSet`.
For boolean flags, consider empty as `false`.
Using `syscall.Getenv` rather than `os.LookupEnv` in order to support
older Golang versions.
by defining `cli.DefaultFlagStringFunc` with a default value that uses
`withEnvHint`, conditionally running a given flag's `FormatValueHelp` if
present.
Closes#257
This is a way to provide hidden flags for app, command and subcommands
For example:
--generate-bash-completion global flag shouldn't be printed along
with other flags as it might generally confuse people into thinking
that 'generate' in-fact would generate a bash completion file for them
to be used along with their app.
Also in general one would want to hide some flags for their apps.
