Actually, looks like we're missing "see docker run --help" in the usage output;

old:

docker: "run" requires a minimum of 1 argument.
See 'docker run --help'.

Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Run a command in a new container

new

"docker run" requires at least 1 argument(s).

Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Run a command in a new container

Is that someone we need to fix here, or globally?

Other than that, re-LGTM

@thaJeztah good point. It's something to do globally 😝
I'll do a follow-up to fix it 😉

ok LGTM, once we get a Windows CI node that isn't broken 😢

it's green! merging 👍

Looks like there are still some edge cases to consider: 😢

$ docker run --name test --rm debian:sid sh -c 'echo hi'
hi
$ docker create --name test debian:sid sh -c 'echo hi'
invalid argument "echo hi" for c: strconv.ParseInt: parsing "echo hi": invalid syntax
See 'docker create --help'.

Darn, it's seeing -c as --cpu-shares?

Indeed, instead of stopping flag processing at the image name like docker run appears to successfully do. 😢

From the looks of the diff, it appears docker create is just missing flags.SetInterspersed(false)

Any command that expects extra flags after positional args needs to set flags.SetInterspersed(false).

That was done for run and a few others.

Cool, sounds like an easy fix (phew). Thanks for finding, @tianon! We should have a test for that as well

Seems to be an issue see #23329