docker cp spinner does not work

[dtronche]

Description

In docker 23, the docker cp command is supposed to use a spinner (#2708)
However, as indicated in Azratosh comment (#2708 (comment)), the behavior is not as expected and big files copy results in hundredth of log lines which makes the use of the quiet mode almost compulsory in practice

Reproduce

run any docker cp command
Environments:

• Debian 11, package docker-ce-cli/bullseye,now 5:23.0.0-1debian.11bullseye
• CentOS 7, package docker-ce-cli-23.0.1-1.el7.x86_64

Expected behavior

The command shall behave as shown in feature video

docker version

Client: Docker Engine - Community
 Version: 23.0.0
 API version: 1.42
 Go version: go1.19.5
 Git commit: e92dd87
 Built: Wed Feb 1 17:43:17 2023
 OS/Arch: linux/amd64
 Context: default

Server: Docker Engine - Community
 Engine:
 Version: 23.0.0
 API version: 1.42 (minimum version 1.12)
 Go version: go1.19.5
 Git commit: d7573ab
 Built: Wed Feb 1 17:43:17 2023
 OS/Arch: linux/amd64
 Experimental: false
 containerd:
 Version: 1.6.16
 GitCommit: 31aa4358a36870b21a992d3ad2bef29e1d693bec
 runc:
 Version: 1.1.4
 GitCommit: v1.1.4-0-g5fd4c4d
 docker-init:
 Version: 0.19.0
 GitCommit: de40ad0

docker info

Client:
 Context: default
 Debug Mode: false
 Plugins:
 buildx: Docker Buildx (Docker Inc.)
 Version: v0.10.2
 Path: /usr/libexec/docker/cli-plugins/docker-buildx
 compose: Docker Compose (Docker Inc.)
 Version: v2.15.1
 Path: /usr/libexec/docker/cli-plugins/docker-compose
 scan: Docker Scan (Docker Inc.)
 Version: v0.23.0
 Path: /usr/libexec/docker/cli-plugins/docker-scan

Server:
 Server Version: 23.0.0
 Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Using metacopy: false
 Native Overlay Diff: true
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 31aa4358a36870b21a992d3ad2bef29e1d693bec
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
 apparmor
 seccomp
 Profile: builtin
 cgroupns
 Kernel Version: 5.10.0-9-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.691GiB
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
 127.0.0.0/8
 Live Restore Enabled: false

Additional Info

No response

[cpuguy83]

This seems to happen when stderr is not a TTY.

e.g. docker cp bigfile foo:/bigfile 2>cp.err.log
I think we could just check for this and not output progress messages.

[cpuguy83]

I've got a branch with a few commits to improve the progress output... first commit fixes this issue.
Putting that here so other people don't waste time working on this as well :)

https://github.com/docker/cli/compare/master...cpuguy83:cli:fix_cp_no_tty?expand=1

[cpuguy83]

Opened #4137

[dtronche]

This seems to happen when stderr is not a TTY.

e.g. docker cp bigfile foo:/bigfile 2>cp.err.log I think we could just check for this and not output progress messages.

Thanks but I'm not sure to understand your analysis. In our configuration, we have the behavior by default even when stderr is not redirected

[cpuguy83]

It's not about the redirect, just if stderr is a TTY or not.