is the whitespace after %s within the quotes intentional here?

also is the printf + word splitting necessary? we could just put k8s.io/code-generator/cmd/ in front of the three BINS entries

yes, the space is needed to produce the right output.

As you raised above, there is a POTENTIAL whitespace issue, but not an ACTUAL issue - all the places we do this are controlled inputs which do not include the user-owned path. They are all either Go package names (as returned by go list - no spaces) or binary names enumerated immediately before. So One option is to leave it as printf.

Exploring:

$ # foo just prints info about its args
$ function foo() { local i=1; for arg; do echo "\$$i: $arg"; i=$((i+1)); done; }

$ foo a b "c d e"
$1: a
$2: b
$3: c d e

$ X=("a" "b" "c d e")

$ printf -- "--arg=\"%s\" " "${X[@]}"; echo;
--arg="a" --arg="b" --arg="c d e" 

That looks OK, but...

$ foo $(printf -- "--arg=\"%s\" " "${X[@]}")
$1: --arg="a"
$2: --arg="b"
$3: --arg="c
$4: d
$5: e"

The shell evaluation of quoted strings doesn't survive. We could do:

$ eval foo $(printf -- "--arg=\"%s\" " "${X[@]}")
$1: --arg=a
$2: --arg=b
$3: --arg=c d e

...but that is easy to misuse or just forget about. Bash arrays and functions are a mess, which is why we have things like read-array which is deeeeep dark magic

or else we take it into our own hands:

$ A=(); for arg in "${X[@]}"; do A+=("--arg=\"$arg\""); done

$ foo "${A[@]}"
$1: --arg="a"
$2: --arg="b"
$3: --arg="c d e"

It's not so bad, but it can't be a function.

Another option is to use the IFS trick ((IFS=,; foo "${X[*]}") - which, while terse, is also a bit brittle (IFS has to be set on a distinct command and [@] does not work). This passes a single --input-dirs=foo,bar,bat rather than --input-dirs=foo --input-dirs=bar --input-dirs=bat.

I'll add commits in a couple styles - you tell me which you think make sense, and then I will back-integrate :)

yes, the space is needed to produce the right output.

As you raised above, there is a POTENTIAL whitespace issue, but not an ACTUAL issue - all the places we do this are controlled inputs which do not include the user-owned path. They are all either Go package names (as returned by go list - no spaces) or binary names enumerated immediately before. So One option is to leave it as printf.

Exploring:

$ # foo just prints info about its args
$ function foo() { local i=1; for arg; do echo "\$$i: $arg"; i=$((i+1)); done; }

$ foo a b "c d e"
$1: a
$2: b
$3: c d e

$ X=("a" "b" "c d e")

$ printf -- "--arg=\"%s\" " "${X[@]}"; echo;
--arg="a" --arg="b" --arg="c d e" 

That looks OK, but...

$ foo $(printf -- "--arg=\"%s\" " "${X[@]}")
$1: --arg="a"
$2: --arg="b"
$3: --arg="c
$4: d
$5: e"

The shell evaluation of quoted strings doesn't survive. We could do:

$ eval foo $(printf -- "--arg=\"%s\" " "${X[@]}")
$1: --arg=a
$2: --arg=b
$3: --arg=c d e

...but that is easy to misuse or just forget about. Bash arrays and functions are a mess, which is why we have things like read-array which is deeeeep dark magic

or else we take it into our own hands:

$ A=(); for arg in "${X[@]}"; do A+=("--arg=\"$arg\""); done

$ foo "${A[@]}"
$1: --arg="a"
$2: --arg="b"
$3: --arg="c d e"

It's not so bad, but it can't be a function.

Another option is to use the IFS trick ((IFS=,; foo "${X[*]}") - which, while terse, is also a bit brittle (IFS has to be set on a distinct command and [@] does not work). This passes a single --input-dirs=foo,bar,bat rather than --input-dirs=foo --input-dirs=bar --input-dirs=bat.

I'll add commits in a couple styles - you tell me which you think make sense, and then I will back-integrate :)