Error messages are wildly inaccurate when DOCKER_CONFIG is set to a file instead of a directory

[Manbeardo]

Description

The CLI's validation behavior appears to run amok when the DOCKER_CONFIG variable is set to a normal file instead of a directory. This creates some serious red herrings when debugging issues caused by a bad DOCKER_CONFIG value.

Reproduce

export DOCKER_CONFIG="$(mktemp -d)"
touch "$DOCKER_CONFIG/config.json"
export DOCKER_CONFIG="$DOCKER_CONFIG/config.json"

# no error
docker version

# no error
docker ps

# error message: 'buildx' is not a docker command.
docker build

# error message: unknown flag: --bootstrap
docker buildx imagetools create --bootstrap

Expected behavior

All docker commands should output an error message indicating that DOCKER_CONFIG must be a directory.

docker version

Client: Docker Engine - Community
 Version:           26.1.0
 API version:       1.43 (downgraded from 1.45)
 Go version:        go1.21.9
 Git commit:        9714adc
 Built:             Mon Apr 22 17:06:56 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Desktop 4.26.1 (131620)
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:08:15 2023
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.25
  GitCommit:        d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
 runc:
  Version:          1.1.10
  GitCommit:        v1.1.10-0-g18a0cb0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    26.1.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.26.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 163
  Running: 3
  Paused: 0
  Stopped: 160
 Images: 121
 Server Version: 24.0.7
 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 logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
 runc version: v1.1.10-0-g18a0cb0
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.5.11-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 12
 Total Memory: 7.662GiB
 Name: docker-desktop
 ID: 4b718373-4d26-45a2-a154-f7d67d862700
 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

WARNING: daemon is not using the default seccomp profile

Additional Info

No response

[osnipezzini]

Same here, i moved to PNG to fix temporarily

[lore-co]

Same