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.