Flag default value is overwritten by environment in help output.

[r10r]

my urfave/cli version is

v2.3.0

Describe the bug

Flag default value should never change in help output.

To reproduce

Build the following program against v2.3.0.

package main

import (
	"github.com/urfave/cli/v2"
	"os"
)

func main() {
	app := cli.NewApp()
	app.Name = "myapp"
	app.Flags = []cli.Flag{
		&cli.StringFlag{
			Name:        "myflag",
			Usage:       "my flag is my flag",
			EnvVars:     []string{"MYFLAG"},
			Value:       "defval",
		},
  }
  app.Run(os.Args)
}

Observed behavior

What did you do?

MYFLAG=foo ./app --help

What did you see happen immediately after the reproduction steps above?

NAME:
   myapp - A new cli application

USAGE:
   app [global options] command [command options] [arguments...]

COMMANDS:
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --myflag value  my flag is my flag (default: "foo") [$MYFLAG]
   --help, -h      show help (default: false)

What did you expect to see?

[...]
GLOBAL OPTIONS:
   --myflag value  my flag is my flag (default: "defval") [$MYFLAG]
   --help, -h      show help (default: false)

Expected behavior

Default value should never change (in help output).

[r10r]

Maybe related to #1181

[r10r]

ping

[vipally]

The default value can changes by Env value or config file, it is the design, not bug.
Refers to the doc
I don't know why no body deals with the issues and PRs.

[r10r]

it is the design, not bug.

@vipally Your comment is kinda confusing. According to your pull requests you do consider this as a bug ?

[r10r]

Kindly ping @lynncyrin. Can someone of the devs please comment whether this is a bug or not? Thanks!

[coilysiren]

👀

[coilysiren]

I don't know why no body deals with the issues and PRs.

Because nobody is paid to pay attention to them 🙂

[coilysiren]

I think this is unambiguously a bug, the EnvVars attribute isn't intended to mock the default value

[coilysiren]

If the docs are currently expecting this behavior, then the docs should be changed too.

I think this is a bug from a logical point of view, but I think it's also important to consider whether or not fixing this would be a breaking change... hopefully the bug here is only with the help text display.

[r10r]

👀

Thanks for looking in :D

@vipally What about closing the duplicate issues and continue discussion here ?

[vipally]

it is the design, not bug.

@vipally Your comment is kinda confusing. According to your pull requests you do consider this as a bug ?

In fact, my PR pays no attention on whether ENV values change the default.
I found some strange of the design, because flag.Value is the default value makes confuse.
In my sense, default value may named as Default but not Value.

[vipally]

👀

Thanks for looking in :D

@vipally What about closing the duplicate issues and continue discussion here ?

Do you mean #1235 ?
I consider them as different and same kind of issues, but not duplicate ones.
I found lots of unexpected behavior on slice filags.

[dearchap]

@urfave/cli What do you all think ? We should change this to have defval instead of val from env for default ?

[abitrolly]

Because nobody is paid to pay attention to them slightly_smiling_face

If there was the option, I would use it right away. :D

What do you all think ? We should change this to have defval instead of val from env for default ?

I think this

MYFLAG=foo ./app --help

Should give this

   --myflag value  my flag is my flag (default: "defval"), env:MYFLAG ("foo")

[julian7]

I’m a bit ambivalent here. First, I LOVE it. However, it still hurts how I found this “feature”: I was presenting to my coworkers what a tool could achieve, which, apparently used urfave/cli. I’ve put my secrets into variables, just to make sure they’ll be kept hidden… and they were, until someone asked for a feature I vaguely remember about, and I had to look it up by looking at the subcommand’s help. I’d say as much as I love them, I’d rather remove it. -- -jul-

…

On 2022. Oct 10., at AM 3:09, dearchap ***@***.***> wrote: @urfave/cli <https://github.com/orgs/urfave/teams/cli> What do you all think ? We should change this to have defval instead of val from env for default ? — Reply to this email directly, view it on GitHub <#1206 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQUPSCHKFVTBVQN5KNDE3WCNUDTANCNFSM4T42MPCA>. You are receiving this because you are on a team that was mentioned.

[abitrolly]

@julian7 users who can run --help can as well read secret from environment variable. However, if one is doing live coding, this can be rather sensitive indeed. I would still leave a possibility to toggle env variable output for not so critical variables, and leave out showing the value by default.

[Dokiys]

@urfave/cli What do you all think ? We should change this to have defval instead of val from env for default ?

I think it's not necessary to output env variable. For example when run rm -rf $SOMEFILES , we should explicitly know what SOMEFILES is.