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.
Prior to this change, this test was failing for me on a new windows
machine, with mismatching drive letters:
helpers_test.go:20: (C:/Users/Foo Bar/cli/altsrc/flag_test.go:195) Expected C:\path\to\source\hello (type string) - Got D:\path\to\source\hello (type string)
Rather than hard-coding the drive letter in the expected path, we can
expect the filepath.Abs'ed version.
This should fix part of #1105.
Some of the docs were lacking or incomplete concerning how to properly
use cli.Exit, cli.HandleExitCoder, and the ExitErrHandler field on cli.App.
This change aims to clarify the usage of those pieces.
I also noticed that we have two identical functions now: cli.Exit and
cli.NewExitError. Since the latter seems to be more recent and less well
documented, I went ahead and marked it as deprecated so that we can keep
our public interface small.
Also added a missing test case for behavior that's been around a while
but was not documented or tested.
Related: #1089
While `HideHelp` hides both `help` command and `--help` flag, `HideHelpCommand`
only hides `help` command and leave `--help` flag as-is.
The behavior of `HideHelp` is untouched in this commit.
Fix#523
Replace #636
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The usage of the `(default: …)` strings are a bit error prone so we now
refactor them into a dedicated helper function.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
