[BUG] compose bash completion doesn't correctly expand service names
Description
Commands are completing as expected, e.g. docker compose b<tab> => docker compose build. But the following symbol, the service name, isn't completed normally. Instead the full list of services is always listed on the terminal no matter what was typed.
Steps To Reproduce
Example project containing two services: myservice and database.
Type docker compose start m<tab>.
Expect this to complete to docker compose start myservice, but nothing happens.
Press <tab> again. Expect to see a list of services beginning with m, but instead all services are listed:
$ docker compose m
database
myservice
Compose Version
Docker Compose version v2.24.5-desktop.1
Docker Environment
Client:
Version: 25.0.3
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1-desktop.4
Path: /Users/mattlaw/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.24.5-desktop.1
Path: /Users/mattlaw/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container. (Docker Inc.)
Version: 0.0.24
Path: /Users/mattlaw/.docker/cli-plugins/docker-debug
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: /Users/mattlaw/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.21
Path: /Users/mattlaw/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.4
Path: /Users/mattlaw/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.0.0
Path: /Users/mattlaw/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/mattlaw/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.4.1
Path: /Users/mattlaw/.docker/cli-plugins/docker-scout
Server:
Containers: 8
Running: 8
Paused: 0
Stopped: 0
Images: 10
Server Version: 25.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.6.12-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 8
Total Memory: 7.755GiB
Name: docker-desktop
ID: c5ec01e4-9f1c-431e-8998-e131afeca227
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
Anything else?
No response
This started to happen on all of my deployments as well. It must've been caused by some recent update, this was not an issue couple of months ago.
This happens with the latest update (Docker Compose version v2.24.5), was working fine before
Confirmed fixed in v2.26.1-desktop.1