namsral/flag

Parse flags, environment variables and config files

flag's Issues

Is there a way to disable the ConfigFlagname of a FlagSet?

I want to use this package, but be able to use the -config flag for my own things, without it interfering in any way. Right now the only way to change the behavior seems to be to set flag.DefaultConfigFlagname to something else, but I would like to do it only for a specific FlagSet, rather than all.

Is this possible at the moment?

Config file parse failure "configuration variable provided but not defined" is not visible to application

When an invalid command line argument is passes, usage information is printed and the application exists by default as per the default ErrorHandling option along with the message "flag provided but not defined: ".

When doing the same thing with a config file passed in via -config however, a similar error is printed "configuration variable provided but not defined", but the application does not exit, nor does there appear to be any way to detect this error within the application either.

Reading individual values from files (eg. docker secrets)

I'd find it useful to read certain parameters from a file, so for example say I have a password command line flag defined. I'd use it like -password=1234 with the flags package, and this package also adds compatibility with PASSWORD=1234 environment variable to fill it in. It would be even better if I could fill it in with a secret, like PASSWORD_FILE=/secrets/password.

lowercase environment variables

In our use case we have to deal with lowercase environment variables, such as http_proxy, used also by wget.

It would be great to have a global option to parse lowercase environment variables. Something like

flag.UseLowercase = true

I can make a Pull Request myself if you agree

Execution with -h should just print the usage instruction and exit

At the moment the execution continues even when executing the program with -h.

I would expect it to just print usage instructions and exit the program immediately, like the original flag package is doing.

Running go test with any of the standard flags throws an "flag provided but not defined:" error

Hi,

When using the this package and running go test with any of the testing package's testflags I get an error.
For example, running go test -v will produce the following :

flag provided but not defined: -test.v

The test.v is used to print out verbose output (https://golang.org/src/testing/testing.go).

chatty= flag.Bool("test.v", false, "verbose: print additional output")

Is there any way to make this package aware of other (Go) flags. This will allow the usage of testflags.

Thanks
-Dom

print error from config file parsing by default

That providing undefined arguments prints some help and exits but -config (nonexistent) doesn't print anything seems like a bit of a mismatch. I realize CommandLine has ExitOnError on by default but figured I'd open up a discussion. What about an explicit check for the file's presence and performing an f.failf in that case?

Required environment variables is a regression

An empty string can be a valid parameter. For example, when connecting to an SMTP or Redis server, empty logins and passwords may mean "Do not use authentication." A recent update forces one to use magical, non-empty values, at least when configuring a program via environment variables, as is common with Dockerized applications.

Still Maintained?

Seems like this hasn't had any activity in quite awhile. Is this still a maintained library?

Support for fixed-size integer types

Hi there, would you accept a PR that adds support for fixed-size integer types?

Motivation

When using smaller types (e.g. int8, uint16) users need to manually cast int/uint and perform bounds checking.

Proposal

It would look like this:

flag.Uint16Var(&HTTPPort, "port", 8080, "A port")

This code would induce a panic (as opposed to a silent wrap-around):

f := 65536  // doesn't fit in a uint16
flag.Uint16Var(&HTTPPort, "port", 8080, "A port")

using config file by default

I always need a config file, and the location of config file is known. I tried setting the config param default value to point to that file, but this package is not looking at it unless I specify the flag again on the command line.

flag.String("config", "settings.conf", "help message for config")

This to me is a bug. Default values are precisely that: default unless over-ridden by command line.

Support Multi Value Flags in Config

For some flags I create my own type so I can apply the flag multiple times and store it in a slice. It looks something like this.

./myapp -multi 1 -multi 2 -multi 3

type arrayFlags []string

func (i *arrayFlags) String() string {
	return "[]"
}

func (i *arrayFlags) Set(value string) error {
	*i = append(*i, value)
	return nil
}

var multi arrayFlags

flag.Var(&multi , "multi", "Apply this multiple times")

This works great but when I try to use a config I always only get the first value.

multi 1
multi 2
multi 3

./myapp -config my.conf

The value of multi is always just [1].

Is there a way I can get this to work when using a configuration file?

type alias for Value, Getter etc.

Could it be a good idea to let interface types like Value and Getter be type-aliases to the interfaces defined in the official flag package?

This would allow e.g. defining an interface for FlagSet in your own applications or libraries, that is able to accept both a FlagSet from this package or a FlagSet from the standard library, when a method with interface parameters is required.

import "flag"

type Value  = flag.Package
type Getter = flag.Getter

Application example:

package example

import "flag"

type FlagSet interface {
    Var(value flag.Value, name string, usage string)
}

func AddFlags(set FlagSet) {
    ...
} 

Add camel case flag name example to readme

It would be nice to rename one of the flag names to a camel case one.

I'd be interested to find in the readme if consumerPort translates to CONSUMER_PORT or CONSUMERPORT as an environment variable.

update:
From this line it seems we just uppercase, so the consumerPort would give us CONSUMERPORT

Parse behaviour is wrong when flag contains "-"

ENV

export NODASH=1
export HAVE_DASH=2

Config file

nodash=10
havedash=20

var noDash string
var haveDash string
flag.StringVar(&noDash, "nodash", "0", "noDash")
flag.StringVar(&haveDash, "have-dash", "0", "haveDash")
flag.Parse()
fmt.Println(nodash, haveDash) // "10" "2",  expected result should be "10" "20"

Support for required flag and Default should be optional

Mostly, defaults are used for local development. On production, everything is passing using the Environment variable. So, if any environment variable is not passed then flag will take default. So, we should add support in that we can say that give flag must be passed

not a drop-in replacement

There is an issue, if you define a flag in a some other package, but not in a main package.

If your main package imports "abc/def/gh", and package "gh" defines a flag "-flag1", while in your main package "flag.Parse()" is called, then:

• the standard 'flag' package successfully parses command line with "--flag1=xyz";
• namsral/flag complains "flag provided but not defined: -flag1" .

`go test -v` stops working

Hi, when I use your library instead of the default flag, I encounter this error when I try to run tests in verbose mode:

$ go test -v
flag provided but not defined: -test.v

Any quick fix for this?

prefix for environment variables

It would be great to have a function like "SetEnvPrefix" or something to be able to add a prefix to the environment variables. As an example:

var age int

flag.IntVar(&age, "age", 27, "my age")
flag.SetEnvPrefix("svc")

And then be able to do the following:

$ SVC_AGE=25 go run gopher.go

What do you think ?

Odd interaction with other libraries using flag behind the scenes

Hi,

You may be interested in this ticket. There is an odd interaction when another library (in this case, the zero-downtime restart library endless) uses flags behind the scene to sneak in its own flags. A number of oddities crop up. To demonstrate, use this code. Compile the sample code to flagtest, and the demonstrations are below:

• The using application's flags become illegal and generate an error if provided (./flagtest -param)
• The library's flags become illegal and generate an error if provided (./flagtest -continue)
• Which help message displayed differs depending on which flags are missed or provided (see the two examples above -- two different messages)

The behavior is the same whether the flag is defined globally, or in the scope of the main() function.

I do not know whether this is particular to fvbock/endless + namsral/flag, or if other flag-using libraries have the same problem with namsral/flag; I haven't investigated it yet. I thought you might like to be aware of the issue.

Release new version

I'm currently relying on the master branch for my builds using dep. Could you make a stable release with latest changes?

Out of Sync with latest go version - Newer fork available jnovack/flag

This repository includes the v1.17.4 of golang/src/flag. We are currently at v1.15 and a number of improvements have been made to the package which are not reflected here.