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

can't use double quote in values passed inside a string slice #370

Open
dbenque opened this issue Dec 29, 2022 · 1 comment
Open

can't use double quote in values passed inside a string slice #370

dbenque opened this issue Dec 29, 2022 · 1 comment

Comments

@dbenque
Copy link

dbenque commented Dec 29, 2022

When using a string slice StringSliceVar it is impossible to pass values with double quotes "

The reason is that a CSVReader is used in the implementation (here) and it does not support ".

One possible solution would be to give the ability to the user to set the LazyQuote mode on the reader.
https://pkg.go.dev/encoding/csv#Reader.LazyQuotes

I faced this problem as I was using a string slice to pass some small piece of json.

Here is a simple program to reproduce the problem:

package main

import (
	"github.com/spf13/pflag"
	"os"
)

func main() {
	fs := pflag.NewFlagSet("Example", pflag.PanicOnError)
	var ss []string
	fs.StringSliceVar(&ss, "slice", []string{}, "test slice")

	if err := fs.Parse(os.Args); err != nil {
		panic(err)
	}
}

To be launched with:

go run main.go --slice='{"delay":"6h"}'

or

go run cmd/test/main.go --slice="{\"delay\":\"6h\"}"

The result should be:

panic: invalid argument "{\"delay\":\"6h\"}" for "--slice" flag: parse error on line 1, column 2: bare " in non-quoted-field
@dbenque
Copy link
Author

dbenque commented Dec 29, 2022

Workaround: if you can you don't plan to use a coma separated value, and you are ok to repeat the parameter multiple times on the command line, you can use the string array that does not attempt a CSV parsing (almost, it does not in the Set, but it does here)

Here is a sample that works:

func main() {
	fs := pflag.NewFlagSet("Example", pflag.PanicOnError)
	var ss []string
	fs.StringArrayVar(&ss, "array", []string{}, "test slice")

	if err := fs.Parse(os.Args); err != nil {
		panic(err)
	}
	fmt.Printf("%#v", ss)
}

with: go run cmd/test/main.go --array='{"delay":"6h"}' --array='{"delay":"8h"}'

jrschumacher pushed a commit to opentdf/otdfctl that referenced this issue Mar 28, 2024
Adds CRUD for subject condition sets, with the JSON relation of
`[]*policy.SubjectSets` passed via a string flag or found in a `.json`
file with the filepath/name provided in a flag on CREATE, and validation
that only one is provided at once. On UPDATE, only a JSON string is
allowed.

There is an open `pflags` issue (since 2022) which is the library under
Cobra's flags implementation which affects the Subject Condition Sets
(SCSs) flag API: spf13/pflag#370.

Unfortunately, this issue means we cannot allow a slice of individual
SCSs passed via CLI as we do with `--label` where each individual label
passed with `--label` populates a `[]string` of all `labels`. In this
case, if we attempt `--subject-set <single subject set json>` to
populate a `[]string` where each index is a JSON string for a single
SCS, we get an error `flag: parse error on line 1, column 3: bare " in
non-quoted-field`. Because of this, we must expect all SCSs being
created via JSON in the CLI to already be joined into the single array
and passed as a single string flag `--subject-sets <json array of all
subject sets in the SCS>`.

There is already support added in this PR for reading from a JSON file
to create the SCS, and any time there is JSON in the CLI it is likely it
will be added via script instead of manually.

See [new issue](#77) around
admin UX of testing Subject Condition Sets before creating.

> [!NOTE]
> This PR was going to introduce reading Subject Sets from a YAML file
as well, but yaml struct tags are not generated in the proto-built
types. If this is needed, it should be discussed further and separately
how the platform could expose YAML tags so consumers do not reimplement
them repeatedly and potentially mistakenly. Perhaps a [new proto
plugin](https://github.com/srikrsna/protoc-gen-gotag) could be utilized.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant