Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange behavior of CLI flags #1948

Closed
3 tasks done
jetexe opened this issue Jul 8, 2024 · 5 comments
Closed
3 tasks done

Strange behavior of CLI flags #1948

jetexe opened this issue Jul 8, 2024 · 5 comments
Labels
area/v3 relates to / is being considered for v3 status/triage maintainers still need to look into this status/waiting-for-response Waiting for response from original requester

Comments

@jetexe
Copy link
Contributor

jetexe commented Jul 8, 2024

Checklist

  • Are you running the latest v3 release? The list of releases is here.
  • Did you check the manual for your release? The v3 manual is here.
  • Did you perform a search about this feature? Here's the GitHub guide about searching.

Problem

Currently if you mark your flag as required and try to call a command with --help flag you will get an error:

Required flag "<name>" not set

Same for the validation: If you want to print help you will get the validation error.

Proposal

I'm suggesting we don't run a validation and required check during help printing

@jetexe jetexe added area/v3 relates to / is being considered for v3 status/triage maintainers still need to look into this labels Jul 8, 2024
@dearchap
Copy link
Contributor

dearchap commented Jul 8, 2024

@jetexe Unfortunately this is expected behavior. This has been an ongoing issue with urfave/cli given its architecture.

@BlackHole1
Copy link
Member

I'm not sure if this is very difficult to achieve, but I would like to know if we can provide a switch in version v3. Something like:

&cli.StringFlag{
	Name:               "name",
	Required:           true,
	HelpExcludeRequire: false // Default: true
},

or

Name: "config",
HelpExcludeRequireFlags: true
Flags: []cli.Flag{
	&cli.StringFlag{
		Name:        "name",
		Required:    true,
	},
},

@tarampampam
Copy link
Contributor

Unfortunately, I have the same problem as described 😞

@jetexe
Copy link
Contributor Author

jetexe commented Jul 11, 2024

provide a switch

The problem is in the prepare process. cli parses flags and command first, and only after that makes a decision to print the help. I wonder if we can ignore validation and required flags errors in case of help printing

@dearchap
Copy link
Contributor

Should be fixed by #1987 . @jetexe please test with latest v3 and let me know,

@dearchap dearchap added the status/waiting-for-response Waiting for response from original requester label Oct 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v3 relates to / is being considered for v3 status/triage maintainers still need to look into this status/waiting-for-response Waiting for response from original requester
Projects
None yet
Development

No branches or pull requests

4 participants