Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
support overriding entrypoint on service create from the cli #29171
Just opening this as a separate issue here from #25303 so it can be tracked. There was as discussion about adding
referenced this issue
Dec 6, 2016
Yes,we've had a lot of discussions about this. We had this implemented for 1.12, but we removed it.
I think the two questions are:
I think the second question should be mostly resolved now that we use
No, the concept of
This is confusing to docker users who weren't previously familiar with shell usage. It's compounded by the fact that users who were previously familiar with certain terminology, such as entrypoint (see entrypoint for previous definition, which supports why this is relevant to images) and args, encountering very imprecise uses of this terminology. When you change the name of the field to
Today, we pass the results of the command line into the
I've created one more table so we don't get confused:
In code, this is the following:
With above, we can say the following:
In regards to this issue, the question is whether or not to allow an image's
The main issue was providing effect argument parsing on the cli under a regular flag.
I don't think there is any confusion about how this works in
The only thing that is relevant to this discussion about CLI flags is this:
It should be obvious from these two commands that in order to be consistent we need an
@dnephin Let me highlight what I said in the post above:
That is why
It is not because of confusion around swarmkit, a lack of consistency or any other reason.
How is the
Isn't this a legacy API?
So, we did end up with shlex...
I played around with
The two flags are accepted, but then the backend only gets
Let's give it a space-separated argument, which should run
I guess I am okay with the shlex version.
Yes its always been impossible to reset the default docker entry point of sh -c from the CLI. Very broken.…
On 7 Dec 2016 20:20, "Stephen Day" ***@***.***> wrote: docker run passes the quoted string to the API as-is, so it's parsed by the backend. Isn't this a legacy API? docker update --args uses shlex. The API excepts a string so I think --entrypoint should work the same as --args and use shlex So, we did end up with shlex... I played around with --entrypoint on docker run and it is quite broken. Let's take this one: $ docker run --entrypoint foo --entrypoint bar -it --rm ubuntu docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"bar\": executable file not found in $PATH". The two flags are accepted, but then the backend only gets bar. Broken. Let's give it a space-separated argument, which should run foo with bar as the arg: $ docker run --entrypoint 'foo bar' -it --rm ubuntu docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"foo bar\": executable file not found in $PATH". Broken. I guess I am okay with the shlex version. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29171 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdcPE2IbhXSTw8ierU_JIu-7fhbDpsdks5rF4WggaJpZM4LFO8z> .
In 1.13 you can reset the entrypoint by specifying an empty string; #23718, or do you mean that it's always executed in the "shell" form?
For flags that don't accept multiple values and are provided multiple times, the later value overwrites the former one. This has always been the case in the docker CLI, and I think it has come up in the past, but changing that behavior was considered too much of a breaking change at that point.
The way to do that in docker would be to set
(yup, it's confusing)
I'm not saying we should repeat the wrong behavior on
It will still result in people expecting the same behavior as
@dnephin do you know if Cobra can enable/disable that behavior on a per-command base?
The current syntax is:
I think the current behavior is the least confusing, albeit not consistent with
@cpuguy83 the problem currently is that you cannot override the entrypoint, for example, running;