Struct-based argument parsing in Go

Overview

go-arg
go-arg

Struct-based argument parsing for Go

Sourcegraph Documentation Build Status Coverage Status Go Report Card


Declare command line arguments for your program by defining a struct.

var args struct {
	Foo string
	Bar bool
}
arg.MustParse(&args)
fmt.Println(args.Foo, args.Bar)
$ ./example --foo=hello --bar
hello true

Installation

go get github.com/alexflint/go-arg

Required arguments

var args struct {
	ID      int `arg:"required"`
	Timeout time.Duration
}
arg.MustParse(&args)
$ ./example
Usage: example --id ID [--timeout TIMEOUT]
error: --id is required

Positional arguments

var args struct {
	Input   string   `arg:"positional"`
	Output  []string `arg:"positional"`
}
arg.MustParse(&args)
fmt.Println("Input:", args.Input)
fmt.Println("Output:", args.Output)
$ ./example src.txt x.out y.out z.out
Input: src.txt
Output: [x.out y.out z.out]

Environment variables

var args struct {
	Workers int `arg:"env"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ WORKERS=4 ./example
Workers: 4
$ WORKERS=4 ./example --workers=6
Workers: 6

You can also override the name of the environment variable:

var args struct {
	Workers int `arg:"env:NUM_WORKERS"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ NUM_WORKERS=4 ./example
Workers: 4

You can provide multiple values using the CSV (RFC 4180) format:

var args struct {
    Workers []int `arg:"env"`
}
arg.MustParse(&args)
fmt.Println("Workers:", args.Workers)
$ WORKERS='1,99' ./example
Workers: [1 99]

Usage strings

var args struct {
	Input    string   `arg:"positional"`
	Output   []string `arg:"positional"`
	Verbose  bool     `arg:"-v,--verbose" help:"verbosity level"`
	Dataset  string   `help:"dataset to use"`
	Optimize int      `arg:"-O" help:"optimization level"`
}
arg.MustParse(&args)
$ ./example -h
Usage: [--verbose] [--dataset DATASET] [--optimize OPTIMIZE] [--help] INPUT [OUTPUT [OUTPUT ...]] 

Positional arguments:
  INPUT 
  OUTPUT

Options:
  --verbose, -v            verbosity level
  --dataset DATASET        dataset to use
  --optimize OPTIMIZE, -O OPTIMIZE
                           optimization level
  --help, -h               print this help message

Default values

var args struct {
	Foo string `default:"abc"`
	Bar bool
}
arg.MustParse(&args)

Default values (before v1.2)

var args struct {
	Foo string
	Bar bool
}
arg.Foo = "abc"
arg.MustParse(&args)

Arguments with multiple values

var args struct {
	Database string
	IDs      []int64
}
arg.MustParse(&args)
fmt.Printf("Fetching the following IDs from %s: %q", args.Database, args.IDs)
./example -database foo -ids 1 2 3
Fetching the following IDs from foo: [1 2 3]

Arguments that can be specified multiple times, mixed with positionals

var args struct {
    Commands  []string `arg:"-c,separate"`
    Files     []string `arg:"-f,separate"`
    Databases []string `arg:"positional"`
}
./example -c cmd1 db1 -f file1 db2 -c cmd2 -f file2 -f file3 db3 -c cmd3
Commands: [cmd1 cmd2 cmd3]
Files [file1 file2 file3]
Databases [db1 db2 db3]

Custom validation

var args struct {
	Foo string
	Bar string
}
p := arg.MustParse(&args)
if args.Foo == "" && args.Bar == "" {
	p.Fail("you must provide either --foo or --bar")
}
./example
Usage: samples [--foo FOO] [--bar BAR]
error: you must provide either --foo or --bar

Version strings

type args struct {
	...
}

func (args) Version() string {
	return "someprogram 4.3.0"
}

func main() {
	var args args
	arg.MustParse(&args)
}
$ ./example --version
someprogram 4.3.0

Overriding option names

var args struct {
	Short         string  `arg:"-s"`
	Long          string  `arg:"--custom-long-option"`
	ShortAndLong  string  `arg:"-x,--my-option"`
}
arg.MustParse(&args)
$ ./example --help
Usage: [--short SHORT] [--custom-long-option CUSTOM-LONG-OPTION] [--my-option MY-OPTION]

Options:
  --short SHORT, -s SHORT
  --custom-long-option CUSTOM-LONG-OPTION
  --my-option MY-OPTION, -x MY-OPTION
  --help, -h             display this help and exit

Embedded structs

The fields of embedded structs are treated just like regular fields:

type DatabaseOptions struct {
	Host     string
	Username string
	Password string
}

type LogOptions struct {
	LogFile string
	Verbose bool
}

func main() {
	var args struct {
		DatabaseOptions
		LogOptions
	}
	arg.MustParse(&args)
}

As usual, any field tagged with arg:"-" is ignored.

Custom parsing

Implement encoding.TextUnmarshaler to define your own parsing logic.

// Accepts command line arguments of the form "head.tail"
type NameDotName struct {
	Head, Tail string
}

func (n *NameDotName) UnmarshalText(b []byte) error {
	s := string(b)
	pos := strings.Index(s, ".")
	if pos == -1 {
		return fmt.Errorf("missing period in %s", s)
	}
	n.Head = s[:pos]
	n.Tail = s[pos+1:]
	return nil
}

func main() {
	var args struct {
		Name NameDotName
	}
	arg.MustParse(&args)
	fmt.Printf("%#v\n", args.Name)
}
$ ./example --name=foo.bar
main.NameDotName{Head:"foo", Tail:"bar"}

$ ./example --name=oops
Usage: example [--name NAME]
error: error processing --name: missing period in "oops"

Custom parsing with default values

Implement encoding.TextMarshaler to define your own default value strings:

// Accepts command line arguments of the form "head.tail"
type NameDotName struct {
	Head, Tail string
}

func (n *NameDotName) UnmarshalText(b []byte) error {
	// same as previous example
}

// this is only needed if you want to display a default value in the usage string
func (n *NameDotName) MarshalText() ([]byte, error) {
	return []byte(fmt.Sprintf("%s.%s", n.Head, n.Tail)), nil
}

func main() {
	var args struct {
		Name NameDotName `default:"file.txt"`
	}
	arg.MustParse(&args)
	fmt.Printf("%#v\n", args.Name)
}
$ ./example --help
Usage: test [--name NAME]

Options:
  --name NAME [default: file.txt]
  --help, -h             display this help and exit

$ ./example
main.NameDotName{Head:"file", Tail:"txt"}

Custom placeholders

Introduced in version 1.3.0

Use the placeholder tag to control which placeholder text is used in the usage text.

var args struct {
	Input    string   `arg:"positional" placeholder:"SRC"`
	Output   []string `arg:"positional" placeholder:"DST"`
	Optimize int      `arg:"-O" help:"optimization level" placeholder:"LEVEL"`
	MaxJobs  int      `arg:"-j" help:"maximum number of simultaneous jobs" placeholder:"N"`
}
arg.MustParse(&args)
$ ./example -h
Usage: example [--optimize LEVEL] [--maxjobs N] SRC [DST [DST ...]]

Positional arguments:
  SRC
  DST

Options:
  --optimize LEVEL, -O LEVEL
                         optimization level
  --maxjobs N, -j N      maximum number of simultaneous jobs
  --help, -h             display this help and exit

Description strings

type args struct {
	Foo string
}

func (args) Description() string {
	return "this program does this and that"
}

func main() {
	var args args
	arg.MustParse(&args)
}
$ ./example -h
this program does this and that
Usage: example [--foo FOO]

Options:
  --foo FOO
  --help, -h             display this help and exit

Subcommands

Introduced in version 1.1.0

Subcommands are commonly used in tools that wish to group multiple functions into a single program. An example is the git tool:

$ git checkout [arguments specific to checking out code]
$ git commit [arguments specific to committing]
$ git push [arguments specific to pushing]

The strings "checkout", "commit", and "push" are different from simple positional arguments because the options available to the user change depending on which subcommand they choose.

This can be implemented with go-arg as follows:

type CheckoutCmd struct {
	Branch string `arg:"positional"`
	Track  bool   `arg:"-t"`
}
type CommitCmd struct {
	All     bool   `arg:"-a"`
	Message string `arg:"-m"`
}
type PushCmd struct {
	Remote      string `arg:"positional"`
	Branch      string `arg:"positional"`
	SetUpstream bool   `arg:"-u"`
}
var args struct {
	Checkout *CheckoutCmd `arg:"subcommand:checkout"`
	Commit   *CommitCmd   `arg:"subcommand:commit"`
	Push     *PushCmd     `arg:"subcommand:push"`
	Quiet    bool         `arg:"-q"` // this flag is global to all subcommands
}

arg.MustParse(&args)

switch {
case args.Checkout != nil:
	fmt.Printf("checkout requested for branch %s\n", args.Checkout.Branch)
case args.Commit != nil:
	fmt.Printf("commit requested with message \"%s\"\n", args.Commit.Message)
case args.Push != nil:
	fmt.Printf("push requested from %s to %s\n", args.Push.Branch, args.Push.Remote)
}

Some additional rules apply when working with subcommands:

  • The subcommand tag can only be used with fields that are pointers to structs
  • Any struct that contains a subcommand must not contain any positionals

This package allows to have a program that accepts subcommands, but also does something else when no subcommands are specified. If on the other hand you want the program to terminate when no subcommands are specified, the recommended way is:

p := arg.MustParse(&args)
if p.Subcommand() == nil {
    p.Fail("missing subcommand")
}

API Documentation

https://godoc.org/github.com/alexflint/go-arg

Rationale

There are many command line argument parsing libraries for Go, including one in the standard library, so why build another?

The flag library that ships in the standard library seems awkward to me. Positional arguments must preceed options, so ./prog x --foo=1 does what you expect but ./prog --foo=1 x does not. It also does not allow arguments to have both long (--foo) and short (-f) forms.

Many third-party argument parsing libraries are great for writing sophisticated command line interfaces, but feel to me like overkill for a simple script with a few flags.

The idea behind go-arg is that Go already has an excellent way to describe data structures using structs, so there is no need to develop additional levels of abstraction. Instead of one API to specify which arguments your program accepts, and then another API to get the values of those arguments, go-arg replaces both with a single struct.

Backward compatibility notes

Earlier versions of this library required the help text to be part of the arg tag. This is still supported but is now deprecated. Instead, you should use a separate help tag, described above, which removes most of the limits on the text you can write. In particular, you will need to use the new help tag if your help text includes any commas.

Comments
  • Adding single and notrunc tag options

    Adding single and notrunc tag options

    As outlined in #49, there is a need to mimic the behavior of other applications by interweaving positional and non-positional parameters.

    This change adds the 'single' option that will force a arg of type []string to only read only the next supplied value

    For example, when dealing with the following arg type:

    type MyArgs struct { Pos []string arg:"positional" Single []string arg:"-s,single" }

    This commit will parse the following command line:

    ./app pos1 pos2 -s=single1 -s=single2 pos3 -s=single3 pos4

    Such that MyArgs.Pos will be [pos1 pos2 pos3 pos4] and Single will be [single1 single2 single3].

    Additionally, because this change needed to modify the way the 'multiple' (ie, how values in slices are accumulated via setSlice) spec type works, it was thought to be prudent to add a 'notrunc' option that allows for default values to be assigned to positional args, so that they can continue to be accumulated, instead of truncating the default slice values.

    Unit tests for the above have also been written and are included in this commit, as well as the addition of a section to README.md and a func defined in example_test.go.

    Fixes #49

    opened by kenshaw 12
  • Support for map[string]string

    Support for map[string]string

    Hello, thank you for the great project. I like the simplicity and project is well maintained.

    I want to replace pflags and viper with this project.

    One of my use cases is to support for a map like flag. As an example, --test foo=bar. I don’t see this documented. I am guessing it is not supported.

    Thanks in advance.

    opened by amir20 11
  • Is there support for determining whether an option was set?

    Is there support for determining whether an option was set?

    As a disclaimer, I'm new to Go and may just be overlooking obvious.

    Short version

    Is it possible to determine whether a user set an environment variable/flag?

    From https://github.com/spf13/cobra/issues/23:

    Is there a way that I can see if a user set a flag, vs. just used the default?

    Desired behavior:

    1. If no config file is specified, use default flag value.
    2. If config file is specified, and the user did not set the flag, use the value in the config file
    3. If config file is specified, but the user did set the flag, use the value specified by the user, even if it's just the default flag value.

    I'm trying to avoid the situation where a non-default is set in the config, but the user wants to force the program to use the default.

    I have a hacky solution that involves parsing the flags twice using different defaults, is there a better approach?

    Details

    I recently began using the pelletier/go-toml package to support providing configuration options via a file in addition to the env vars/flags support that this package provides.

    I first removed the default struct tag from the config struct since pelletier/go-toml supports that same struct tag name and my hope was that I would learn how to "feather" multiple configuration sources together in order to create a composite configuration struct of user-specified and default settings. I moved the job of applying default settings back to a basic constructor that I'm using to setup a default config object.

    I then "merge" in a file config struct, overwriting default values in the destination struct with non-default values from the incoming/source struct. This seemed to make sense during the initial implementation, but after a time I came to realize (even being new) that this was not the ideal approach; using this approach still allowed for invalid values to creep in:

    1. the default constructor gives sane initial values to a new config struct (i.e., "base" struct)
    2. create config structs to hold config file settings and env vars/flag settings
    • now three config structs
    1. the config file introduces a non-default value to its copy of the config struct
    2. the args package is provided a default value via flag and the user assumes that their explicit choice will override settings from the config file
    3. config struct merging takes place which checks for non-default values in the "incoming" struct and copies them into the "base" struct, overwriting any values there
    4. when the env vars/flags config struct is evaluated, the explicit value that happens to be the initial default value is examined, and then discarded
    5. the values specified in the config file end up overriding explicit default values chosen via env vars/command-line

    In the end, it looks like I need to check to see if the user specified a value explicitly and use that, likely continuing to apply at least light validation to discovered values prior to assigning it to the config struct.

    opened by atc0005 10
  • Attempts to use go-arg in tests:

    Attempts to use go-arg in tests: "error: unknown argument -test.timeout=10m0s"

    I'm doing something wrong, but I don't know enough to spot the exact cause. Is this is bug with the package or something I'm doing due to my being new to Go testing?

    Example:

    package main
    
    import (
    	"os"
    	"testing"
    
    	"github.com/alexflint/go-arg"
    )
    
    type TestConfig struct {
    	Option1 int  `arg:"--age,env:TESTING_OPTION1" help:"Placeholder for option 1"`
    	Option2 bool `arg:"--keep-old,env:TESTING_OPTION2" help:"Placeholder for option 2"`
    }
    
    func TestGoArgReproduceProblemSimpler(t *testing.T) {
    	envConfig := TestConfig{}
    	os.Setenv("ELBOW_FILE_AGE", "3")
    	arg.MustParse(&envConfig)
    }
    

    Error from failed test:

    $ go test -v
    === RUN   TestGoArgReproduceProblemSimpler
    Usage: goarg-issue97.test.exe [--age AGE] [--keep-old]
    error: unknown argument -test.timeout=10m0s
    exit status 4294967295
    FAIL    github.com/atc0005/goarg-issue97        0.261s
    
    $ cat go.mod
    module github.com/atc0005/goarg-issue97
    
    go 1.13
    
    require github.com/alexflint/go-arg v1.2.0
    

    I haven't published the code via a Git repo, but can do that if it would be helpful.

    opened by atc0005 9
  • Add default values to usage

    Add default values to usage

    Check if the value isn't it's zero value and if not add a default value to the usage text.

    Updated implementation of default values in usage from discussion in #18

    opened by walle 9
  • Option Group Default or Is It a Default

    Option Group Default or Is It a Default

    This may already be possible and I'm just overlooking somehow but I was wondering if option groups are part of the spec. What I'm specifically looking for is to make certain options part of a group and be able to check if anything in the group was set at all. This would facilitate the ability to define a default for an option that is only active when nothing in the group was set. If that's not a thing is there a way to check if a variable was actually set and not just defaulted? That would also provide the functionality I'm looking for.

    opened by runeimp 8
  • Add support for environment variables

    Add support for environment variables

    I decided to take a stab at #2 and this is what I came up with.

    Adding in a new tag env, if provided, go-arg will look for an environment variable to preload the argument from. Using the tag on it's own arg:"env" by default it will use strings.ToUpper(field.Name) of the argument, or else you can override the name of the environment variable via arg:"env:ENV_VAR".

    opened by brettlangdon 8
  • Can't reimplement MustParse behaviour when using NewParser

    Can't reimplement MustParse behaviour when using NewParser

    MustParse is really helpful: https://github.com/alexflint/go-arg/blob/74af96c6ccf404613c251bca4814d32c69047c5f/parse.go#L85-L95

    However, if you want to use a custom Config, you have to call NewParser() which returns a *Parser but hasn't gone through the steps MustParse takes. Though I can implement most of MustParse myself again by calling parser.Parse(os.Args) first and then switching on the resulting err like MustParse does and calling the exported WriteHelpForSubcommand() and FailWithSubcommand().

    I can't access version and lastCmd since those are unexported and there doesn't appear to be an exported equivalent. Version I can still get to using something like &args.Version() or having a func Version(), but lastCmd appears completely unaccessible.

    opened by daenney 7
  • Fix providing multiple values via environment variables

    Fix providing multiple values via environment variables

    Providing values to a slice of strings (or any other type of slices) resulted in an error like this one: error: error processing environment variable EXAMPLE: cannot parse into []string.

    opened by illia-v 7
  • Args with type parameters don't work when not passed

    Args with type parameters don't work when not passed

    So I have this struct I've defined:

    type JSONValue[T any] struct {
    	val T
    }
    
    func (v *JSONValue[T]) Get() T {
    	return v.val
    }
    
    func (v *JSONValue[T]) UnmarshalText(data []byte) error {
    	return json.Unmarshal(data, &v.val)
    }
    

    I am trying to use it my args like this:

    type Args struct {
        // ...
        Environment JSONValue[map[string]string] `arg:"--env"`
        // ....
    }
    

    (It has to be this way for Reasons™)

    When I pass --env it works just fine, however if I omit it then I get the following error:

    error: error processing default value for --environment: invalid character 'm' looking for beginning of object key string
    
    opened by slnt 6
  • add FailSubcommand, WriteUsageForSubcommand, WriteHelpForSubcommand

    add FailSubcommand, WriteUsageForSubcommand, WriteHelpForSubcommand

    Closes #134 #135 #139

    This pr makes it possible to print usage and help text for explicit subcommands. It adds three new functions:

    Parser.WriteUsageForSubcommand
    Parser.WriteHelpForSubcommand
    Parser.FailSubcommand
    

    These behave like their non-subcommand cousins, except that they also take a subcommand name (or a sequence of subcommand names in the case of nested subcommands)

    opened by alexflint 6
  • Global env var prefix

    Global env var prefix

    Hey, is it possible to have a global prefix for environment variables to make then unique? Like vipers viper.SetEnvPrefix("prefix") resulting in the environment variables being search: PREFIX_*.

    opened by milkpirate 0
  • Inconsistency in default value override

    Inconsistency in default value override

    Reference

    I am building a bunch of independent microservices of which everyone uses the same set of Arguments (some with default values). I then override some of the default values in the services (because some services need different default values than the majority) before parsing the arguments, to get an idea:

    var args Args
    
    func main() {
    	// override defaults
    	args.SomeBool = false
    	args.SomeString = "override"
    	
    	arg.MustParse(&args)
    

    The Args struct is defined globally for everyone:

    type Args struct {
    	SomeString string `arg:"--some-string" default:"test"`
    	SomeBool   bool   `arg:"--some-bool" default:"true"`
    	.
    	.
    	.
    }
    

    The actual Issue

    While overriding bool values I noticed that values that have a default value of "true" in the struct, can't be overridden to "false" but overriding a "false" default value to "true" works. Seems a bit strange to handle this differently, is this on purpose?

    v2-ideas 
    opened by gobsej 3
  • help and version show in Positional arguments on subcommands if there's no other options

    help and version show in Positional arguments on subcommands if there's no other options

    When you define a struct which only has positional arguments, the built in --help and --version are printed as part of the positional arguments, instead of the options on subcommands.

    On the "root", it works as expected:

    type root struct {
    	Test string `arg:"positional"`
    }
    
    func main() {
    	arg.MustParse(&root{})
    }
    
    $ go run main.go --help
    Usage: main [TEST]
    
    Positional arguments:
      TEST
    
    Options:
      --help, -h             display this help and exit
      --version              display version and exit
    

    But with a subcommand (with 1 or multiple positionals):

    type root struct {
    	PosOnly *PosOnly `arg:"subcommand:posonly"`
    }
    
    type PosOnly struct {
    	INPUT  string `arg:"positional"`
    	OUTPUT string `arg:"positional"`
    }
    
    func main() {
    	arg.MustParse(&root{})
    }
    
    $ go run main.go --help
    Usage: main <command> [<args>]
    
    Options:
      --help, -h             display this help and exit
      --version              display version and exit
    
    Commands:
      posonly
    
    $ go run main.go posonly --help
    Usage: main posonly [INPUT [OUTPUT]]
    
    Positional arguments:
      INPUT
      OUTPUT
      --help, -h             display this help and exit
      --version              display version and exit
    

    But add an option:

    type root struct {
    	PosOnly *PosOnly `arg:"subcommand:posonly"`
    }
    
    type PosOnly struct {
    	INPUT  string `arg:"positional"`
    	OUTPUT string `arg:"positional"`
    	Test   string `arg:"-t" default:"test"`
    }
    
    func main() {
    	arg.MustParse(&root{})
    }
    
    $ go run main.go posonly --help
    Usage: main posonly [--test TEST] [INPUT [OUTPUT]]
    
    Positional arguments:
      INPUT
      OUTPUT
    
    Options:
      --test TEST, -t TEST [default: test]
      --help, -h             display this help and exit
      --version              display version and exit
    
    opened by daenney 0
  • Prototype v2

    Prototype v2

    This PR will introduce a v2 of go-arg, to be imported with

    import "github.com/alexflint/go-arg/v2
    

    It should be backwards with v1 for about 95% of users. If you only used arg.MustParse then you can use v2 without modifications to your code. The main changes are:

    • add Parser.ProcessCommandLine, Parser.ProcessEnvironment, Parser.ProcessDefaults so that you can control the order in which things are loaded
    • add Parser.OverwriteWithCommandLine, Parser.OverwriteWithEnvironment, Parser.OverwriteWithDefaults for further control over which arguments get overwritten when by which other arguments
    • Drop the Config struct in favor of a list of ParserOptions to NewParser

    Features still to be implemented on this branch:

    • Bash autocomplete support
    • Custom templates for help and usage text

    For users and contributors to go-arg: please leave your feedback and suggestions on this PR.

    opened by alexflint 1
  • Configurable version in usage output

    Configurable version in usage output

    Right now, this library will always output the result of Version() at the start of the usage output: https://github.com/alexflint/go-arg/blob/74af96c6ccf404613c251bca4814d32c69047c5f/usage.go#L84-L86

    From my own observations, doing this is fairly uncommon amongst the CLI utilities installed on my system, especially for those that provide a dedicated flag to retrieve the version. To me personally it also feels a little out of place. If I were going to include the version information in usage output I would probably do it in the epilogue, not in the prologue.

    Would you accept a PR which makes this configurable? Something like a func (args) VersionInHelp() bool {} that could return false causing the Version() to not be emitted, or a flag on Config?

    v2-ideas 
    opened by daenney 5
  • Add arguments group

    Add arguments group

    Argument groups allow for nesting structs of logically related arguments. Although similar to sub commands an argument group does not require a trigger keyword (the command) and is compatible with both nested structs as well as struct pointers.

    Resolves #179 with test coverage proving environment-only arguments are populated properly, and help messages now properly displays the help line for the (environment only) argument.

    opened by SebastiaanPasterkamp 3
Releases(v1.4.3)
Owner
Alex Flint
Monastic; AI safety enthusiast; roboticist; entrepreneur and ex-founder; computer vision PhD; currently training at a monastery in the Bay Area.
Alex Flint
minigli is a tiny command argument parser for Go.

minigli is a tiny command argument parser for Go.

hitoshi44 0 Jan 29, 2022
command argument completion generator for spf13/cobra

Command argument completion generator for cobra. You can read more about it here: A pragmatic approach to shell completion.

null 73 Dec 26, 2022
Go generator to copy values from type to type and fields from struct to struct. Copier without reflection.

Copygen is a command-line code generator that generates type-to-type and field-to-field struct code without adding any reflection or dependenc

SwitchUpCB 218 Dec 29, 2022
Automatically sets up command line flags based on struct fields and tags.

Commandeer Commandeer sets up command line flags based on struct fields and tags. Do you... like to develop Go apps as libraries with tiny main packag

Matthew Jaffee 162 Dec 1, 2022
Flag is a simple but powerful command line option parsing library for Go support infinite level subcommand

Flag Flag is a simple but powerful commandline flag parsing library for Go. Documentation Documentation can be found at Godoc Supported features bool

null 123 Sep 26, 2022
Idiomatic Go input parsing with subcommands, positional values, and flags at any position. No required project or package layout and no external dependencies.

Sensible and fast command-line flag parsing with excellent support for subcommands and positional values. Flags can be at any position. Flaggy has no

Eric Greer 815 Jan 1, 2023
Generate flags by parsing structures

Flags based on structures. The sflags package uses structs, reflection and struct field tags to allow you specify command line options. It supports di

null 145 Nov 24, 2022
Go library for Parsing Ansible inventory files

aini Go library for Parsing Ansible inventory files. We are trying to follow the logic of Ansible parser as close as possible. Documentation on ansibl

Relex 80 Jan 5, 2023
elf binary parsing utility written in Go.

What is it ? go-readelf is a small elf binary parser currently capable of printing relocation entries, elf header, sections and Symbols. It utilizes G

null 57 Nov 9, 2022
A rich tool for parsing flags and values in pure Golang

A rich tool for parsing flags and values in pure Golang. No additional library is required and you can use everywhere.

ALi.w 14 Jan 25, 2022
Package varflag implements command-line flag parsing into vars.Variables for easy type handling with additional flag types.

varflag Package flag implements command-line flag parsing into vars.Variables for easy type handling with additional flag types. varflag Flags String

Marko Kungla 2 Aug 2, 2022
Rdelf2json - CLI application for parsing ELF and converting to json

rdelf2json CLI application for parsing ELF and converting to json Install go ins

kinpoko 0 Jan 22, 2022
🚀 Platform providing a powerful and fast public script parsing API dedicated to the Skript community.

SkriptMC-Parser is currently a prototype in the early stages of development of a system that allows the Skript community to test their scripts via a public API for potential errors or warnings. This is a quick and easy way to check your scripts without having to set up a Spigot server on your environment.

Romain 0 Mar 3, 2022
Automatically generate Go (golang) struct definitions from example JSON

gojson gojson generates go struct definitions from json or yaml documents. Example $ curl -s https://api.github.com/repos/chimeracoder/gojson | gojson

Aditya Mukerjee 2.6k Jan 1, 2023
Easy to use library and CLI utility to generate Go struct from CSV files.

csv2struct Easy to use library and CLI utility to generate Go struct from CSV files. As a benefit, it's fully compatible with csvutil. So, structs gen

Ivan Maliovaniy 12 Nov 7, 2022
Use the command to convert arbitrary formats to Go Struct (including json, toml, yaml, etc.)

go2struct-tool Use the command to convert arbitrary formats to Go Struct (including json, toml, yaml, etc.) Installation Run the following command und

Afeyer 1 Dec 16, 2021
A simple golang marshaller from commandline to a struct

flagmarshal SYNOPSIS A simple golang marshaller from commandline to a struct ParseFlags(structptr interface{}) error DESCRIPTION Very simple implement

null 0 Jan 22, 2022
Small CLI based programs for solving structural engineering design problems based on the book 'Structural Concrete'

Small CLI based programs for solving structural engineering design problems based on the book 'Structural Concrete' written by M. Nadim Hassoun and Akhtem Al-Manaseer (edition-6)

Muhammad Usman Shamsi 1 Nov 26, 2021
Tag-based environment configuration for structs

env Tag-based environment configuration for structs. Installation $ go get -u github.com/codingconcepts/env Usage package main import ( "fmt" "log"

Coding Concepts 102 Dec 23, 2022