peterbourgon / ff

Flags-first package for configuration

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot have -x and -X as separate flags.

xpufx opened this issue · comments

commented

I tried to use lowercase and uppercase short flags for two different parameters and received a 'duplicate flag' error. As far as I know the runes 'x' and 'X' are not equivalent. I also know a lot of CLIs allow this kind of use - especially when there are a lot of flags. Is the behavior intentional?

package main

import (
        "errors"
        "fmt"
        "os"

        "github.com/peterbourgon/ff/v4"
        "github.com/peterbourgon/ff/v4/ffhelp"
)

var (
        severity string
        service  string
)

func main() {
        fs := ff.NewFlagSet("mycommand")
        fs.StringVar(&severity, 's', "severity", "", "")
        fs.StringVar(&service, 'S', "service", "", "")

        err := ff.Parse(fs, os.Args[1:])
        switch {
        case errors.Is(err, ff.ErrHelp):
                fmt.Fprintf(os.Stderr, "%s\n", ffhelp.Flags(fs))
                os.Exit(0)
        case err != nil:
                fmt.Fprintf(os.Stderr, "error: %v\n", err)
                os.Exit(1)
        }
}

That's true, but ff allows flags to be set via env vars, thru a mapping which uppercases the names (as is idiomatic). That's the thing that's triggering the duplicate flag error -- you can't distinguish s from S after that transformation.

There are a few paths forward here:

  1. Keep the status quo -- effectively rejecting this use case in all situations
  2. Allow these flags to be registered, but fail Parse if it's asked to read env vars
  3. Allow these flags to be registered, but ignore them when reading env vars

Although I'm happy with (1), I would also consider (2). And I think (3) doesn't really work, because that's quite unexpected behavior, and difficult to signal back to the caller/user.

commented

I wasn't aware that short parameters can also be passed as environment variables in ff, or in any cli too for that matter. I understand the conflict now.

I am unable to comment on the path forward. In my opinion of one person, environment variabeles should probably only accept long flags. Though since this library is already being used it might not be wise to change the behavior anymore.

Thank you for your response and also thanks for the software. It really does take care of cli flag requirements quite nicely with a lot of extra features coming for free.

Sorry to resurrect a closed issue. I just ran into this, and option (2) would get my vote if this issue comes up again.

In my opinion of one person, environment variabeles should probably only accept long flags.

Consider this the opinion of, at least, two people. 😁 I can't imagine how referencing a single-letter environment variable would be desirable. "Why is an environment variable called V being set? 🤔"