canceling "docker volume prune" does not consistently print a newline, and exits with non-zero status

[thaJeztah]

Description

When terminating docker volume prune using CTRL-C, the CLI terminates, but no newline is printed at the end, causing the shell to continue on the same line. It also exits with a non-zero exit code (255). Behavior is inconsistent between shells though (perhaps some shells compensate for the missing newline, and add them implicitly?).

Reproduce

On Bash on macOS (very old one shipping with macOS);

bash-3.2$ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^Cbash-3.2$ echo $?
255
bash-3.2$

Using N (don't prune) or ENTER (default: also N), the CLI terminates cleanly with a zero exit-code (but also prints a message, which likely shouldn't be printed 😅);

bash-3.2$ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] N
Total reclaimed space: 0B
bash-3.2$ echo $?
0

Interestingly, on a more current version of Bash () on Linux, a newline is printed, but the exit-code is also non-zero, but different (130);

root@debian-s-1vcpu-1gb-ams3-01:~# docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C
root@debian-s-1vcpu-1gb-ams3-01:~# echo $?
130

root@debian-s-1vcpu-1gb-ams3-01:~# bash --version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

On zsh (default now on macOS), a newline is printed, but also exits with a non-zero exit code;

thajeztah@m1book ~ % docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C%
thajeztah@m1book ~ % echo $?
255
thajeztah@m1book ~ %

And same for Fish;

 ~  docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C⏎
 !  ~  echo $status
255
 ~ 

Expected behavior

I expect a newline to be printed, and the command to exit with a zero exit status.

docker version

Client:
 Cloud integration: v1.0.35+desktop.10
 Version:           25.0.1
 API version:       1.44
 Go version:        go1.21.6
 Git commit:        29cf629
 Built:             Tue Jan 23 23:06:12 2024
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.28.0 (135377)
 Engine:
  Version:          25.0.1
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       71fa3ab079ec13d17257f86fa92db8d7f24802f1
  Built:            Wed Jan 24 09:49:39 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.27
  GitCommit:        a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc:
  Version:          1.1.11
  GitCommit:        v1.1.11-0-g4bccb38
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

not relevant

Additional Info

No response

[thaJeztah]

cc @laurazard @krissetto

[thaJeztah]

Ah! 🤦 🤦 🤦

This looks to be another issue with compose-cli. When calling the CLI directly, the newline issue work as expected. It also shows the difference in exit-status; without the compose-cli wrapper, it exits with 130

(but we still need to look why it's not a zero exit code!);

bash-3.2$ com.docker.cli volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C
bash-3.2$ echo $?
130

[laurazard]

Hmm, the exit code issue is interesting I guess. Since we're in a confirmation dialogue, I guess your intuition is that a CTRL-C = "user said no, valid input" exit 0, but otoh strictly from the technical perspective one situation is "we prompted the user for a question and the user replied" and the other is "we prompted the user for a question and in the meantime received a SIGINT". Do we have this behavior with all our confirmation dialogues?

[thaJeztah]

Yeah, we should definitely look what conventions (or recommendations) are for this (perhaps POSIX or elsewhere defines some?)

I guess the TL;DR here is that CTRL-C was my instinctive reaction "oh, no, let's not do that". Which of course is the lazy way of "what options must I pick / key must I press to cancel this operation?"

In this case, I (instinctively) would expect "no action is taken (yet), other than asking the user to confirm", which likely wouldn't really warrant a forceful termination (3 strikes, you're out).

Not sure what the behavior would expected to be though once the pruning started (which can take some time to run!). To some extent, I'm tempted to say that (given it's a server-side operation), it'd still be fine for the client to terminate (and disconnect) immediately, because the server (daemon) should be responsible for gracefully handling that. But of course "it depends" (if the client also has to do graceful termination) 😂 so... likely... buildx (in this case) is the best judge here.

w.r.t. the 130 exit code; wondering if that's a bug somewhere (e.g. converting a context.Cancelled error into "whatever"). The 255 exit-status produced by compose-cli is probably a side-effect of this (it may have logic to convert any "non-zero" status code from the executed (CLI) binary.

(Wondering if 255 here is -1 and an integer overflow 😂 - I recall we had some old code using -1 in some spots)

[krissetto]

I don't think POSIX defines a standard for the use of SIGINT signals at a user confirmation prompt. If the signals are uncaught, i've seen the 128+signal number used as a convention (could that be our 130 result?) but maybe further testing with common tools is warranted.

Generally I'd agree with considering CTRL+C as an equivalent of inputting n/N at a confirmation prompt, and trying to standardize whatever approach we decide on going with

[Benehiko]

I can take a jab at this