The SliceFlag implementation and associated aliases (MultiStringFlag, etc)
extend the existing slice implementations (StringSliceFlag, etc) to support
actual slices as the flag value and destination.
This change also fixes various bugs in the existing implementation. Notably,
the StringSliceFlag.Apply implementation would modify the input (default)
Value, if an env var was set, and no destination was provided. The bugs fixed
in the other three implementations were all already fixed in either
StringSliceFlag, or in one case (ignoring empty env var) in Float64SliceFlag.
Adds a `Destination` field for the `TimestampFlag` type that allows you to specify a pointer to
a `Timestamp` rather than having to grab the `Timestamp` from the `cli.Context` using the flag
name.
If you allow a flag to be set from environment variables or files and
a parse error occurs from one of them, it is very useful for the error
message to mention where the value came from.
Without this, it can be difficult to notice an error caused by an
unexpected environment variable being set.
Implements #1167.
Instead of just resetting the temp dir, let's reset all environment
variables.
Environment variables are a pain for testing. A more reliable solution
would be to refactor all functions that read from the environment to
take the environment as an explicit argument, and then provide a
consistent environment during testing. But that would be a significantly
larger change than this one.
Related to #1105.
In some windows setups, os.TempDir() will return something like
"C:\WINDOWS" if none of the expected environment variables (TMP, TEMP,
USERPROFILE) are set, and then functions that try to create temporary
files or directories will fail since this is not writable.
Several tests in flag_test.go clear the environment and then set a small
number of specific environment variables for the test, triggering the
following error in TestFlagFromFile when I run `go test ./...` on a new
windows machine:
flag_test.go:1667: open C:\WINDOWS\urfave_cli_test851254863: Access is denied.
To work around this, we can check the temp directory before calling
os.Clearenv() and use that directory explcitly in functions that
take the temp directory.
This fixes part of #1105.
