When attaching to a container, hijack puts the terminal in raw mode,
and local echo is disabled. In normal cases, the terminal is restored
once the container detaches;
6f856263c2/cli/command/container/hijack.go (L40-L44)
However, when the CLI is forced to exit (after 3 signals), we `os.Exit(1)`,
which causes defers to not be executed, and because of this, the terminal
not being restored.
For example; start a container that's attached;
docker run -it --rm --sig-proxy=false alpine sleep 20
In another terminal send a SIGINT 3 times to force terminate;
kill -sINT $(pgrep -af docker\ run)
kill -sINT $(pgrep -af docker\ run)
kill -sINT $(pgrep -af docker\ run)
The first terminal shows that the docker cli was terminated;
got 3 SIGTERM/SIGINTs, forcefully exiting
However, the terminal was not restored, so local echo is disabled, and
typing any command in the terminal does not show output (a manual `stty echo`
is needed to restore).
With this patch, the terminal is restored before we forcefully exit the
docker CLI. Restoring is a no-op if there's no previous state, so we
can unconditionally execute this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `--platform` flag originally was added for the experimental LCOW
feature and only accepted the target operating system. Current versions
of Docker allow passing both OS and Architecture, so updating the
documentation to reflect this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Put the content related to `--changes` under a heading with the correct
anchor, so that it will be linked from the "options" table.
- Move note about `sudo` to be under the right example.
- Update some examples to directly read from a file instead of piping.
- Add heading for the `--message` flag.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Produce an error if the `--type` flag was set, but an empty value
was passed.
Before this patch:
docker inspect --type "" foo
# json output
docker inspect --type unknown foo
"unknown" is not a valid value for --type
With this patch:
docker inspect --type "" foo
type is empty: must be one of "config", "container", "image", "network", "node", "plugin", "secret", "service", "task", "volume"
docker inspect --type unknown foo
unknown type: "unknown": must be one of "config", "container", "image", "network", "node", "plugin", "secret", "service", "task", "volume"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch:
docker inspect --help | grep '\-\-type'
--type string Return JSON for specified type
With this patch:
docker inspect --help | grep '\-\-type'
--type string Only inspect objects of the given type
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, flags and arguments would complete using filenames
from the current directory;
docker inspect --type <TAB>
AUTHORS CONTRIBUTING.md docs/ Makefile SECURITY.md
...
docker inspect <TAB>
With this patch, no completion is provided;
docker inspect --type <TAB>
# no results
docker inspect <TAB>
# no results
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When generating our docs, flag-descriptions are currently expected
to be under the "examples" section for them to be linked correctly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `-i` and `-t` options are not needed, as the `pwd` command does not require a TTY nor an interactive session. Drop them to simplify the example and avoid causing unnecessary confusion to the reader.
Signed-off-by: 林博仁(Buo-ren Lin) <buo.ren.lin@gmail.com>
Before this change, some errors could be ambiguous as they did not
distinguish a flag to be omitted, or set, but with an empty value.
For example, if a user would try to loging but with an empty username,
the error would suggest that the `--username` flag was not set (which
it was);
I don't have `MY_USERNAME` set in this shell;
printenv MY_USERNAME || echo 'variable not set'
variable not set
Now, attempting to do a non-interactive login would result in an
ambiguous error;
echo "supersecret" | docker login --password-stdin --username "$MY_USERNAME"
Must provide --username with --password-stdin
With this patch applied, the error indicates that the username was empty,
or not set;
echo "supersecret" | docker login --password-stdin --username "$MY_USERNAME"
username is empty
echo "supersecret" | docker login --password-stdin
the --password-stdin option requires --username to be set
echo "supersecret" | docker login --password-stdin --password "supersecret"
conflicting options: cannot specify both --password and --password-stdin
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `GetSlice()` function is part of cobra's [cobra.SliceValue] interface,
and duplicates the older `GetAll()` method. This patch deprecates the
`GetAll()` method in favor of `GetSlice()`.
[cobra.SliceValue]: https://pkg.go.dev/github.com/spf13/cobra@v1.9.1#SliceValue
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was parsing the same URL twice; first to detect the
scheme, then again (through ssh.ParseURL) to construct a ssh.Spec.
Change the function to use the URL that's parsed, and use ssh.NewSpec
instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `GetSlice()` function is part of cobra's [cobra.SliceValue] interface,
and duplicates the older `GetAll()` method. This patch changes our use
of the `GetAll()` method with the intent to deprecated it in future.
[cobra.SliceValue]: https://pkg.go.dev/github.com/spf13/cobra@v1.9.1#SliceValue
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Cobra's shell completion has specific rules to decide whether a flag can
be accepted multiple times. If a flag does not meet that rule, it only
completes the flag name once; some of those rules depend on the "type"
of the option to end with "Array" or "Slice", which most of our options
don't.
Starting with Cobra 1.9, it also checks whether an option implements
the [cobra.SliceValue] interface (see [spf13/cobra 2210]).
This patch implements the [cobra.SliceValue] interface on ListOpts, so
that these options can be completed multiple times.
In a follow-up, we can update our code to replace our uses of `GetAll()`,
which is identical with the `GetSlice()` method, and potentially deprecate
the old method.
Before this patch, ListOpts would only be completed once when completing
flag names. For example, the following would show the `--label` flag the
first time, but omit it if a `--label` flag was already set;
docker run--l<TAB>
--label (Set meta data on a container) --link-local-ip (Container IPv4/IPv6 link-local addresses)
--label-file (Read in a line delimited file of labels) --log-driver (Logging driver for the container)
--link (Add link to another container) --log-opt (Log driver options)
docker run --label hello --l<TAB>
--label-file (Read in a line delimited file of labels) --link-local-ip (Container IPv4/IPv6 link-local addresses) --log-opt (Log driver options)
--link (Add link to another container) --log-driver (Logging driver for the container)
With this patch, the completion script correctly identifies the `--label`
flag to be accepted multiple times, and also completes it when already
set;
docker run --label hello --l<TAB>
--label (Set meta data on a container) --link-local-ip (Container IPv4/IPv6 link-local addresses)
--label-file (Read in a line delimited file of labels) --log-driver (Logging driver for the container)
--link (Add link to another container) --log-opt (Log driver options)
[cobra.SliceValue]: https://pkg.go.dev/github.com/spf13/cobra@v1.9.1#SliceValue
[spf13/cobra 2210]: https://github.com/spf13/cobra/pull/2210
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, `docker stack deploy` would not validate the image
reference on the client side, depending on the daemon to return an error,
which was not always easy to interpret;
docker stack deploy -c docker-compose.yaml mystack
Creating service mystack_myservice
failed to create service mystack_myservice: Error response from daemon: rpc error: code = InvalidArgument desc = ContainerSpec: image reference must be provided
IMAGE_NAME=FOOBAR docker stack deploy -c docker-compose.yaml mystack
Creating service mystack_myservice
failed to create service mystack_myservice: Error response from daemon: rpc error: code = InvalidArgument desc = ContainerSpec: "FOOBAR" is not a valid repository/tag
With this patch, the CLI validates the image-reference for each service,
producing an error if the reference is empty or invalid.
docker stack config -c docker-compose.yaml
invalid service myservice: no image specified
IMAGE_NAME=FOOBAR ~/Projects/cli/build/docker stack deploy -c docker-compose.yaml mystack
invalid image reference for service myservice: invalid reference format: repository name (library/FOOBAR) must be lowercase
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
