.env file doesn't recognize $PWD variable

[lumnn]

Description

Since the update to v2 the .env file doesn't have $PWD variable set.

I've create a small git repository for reproducing the error you can find here: https://gitlab.com/lumnn/docker-compose-env-error

Basically I've created an .env file with custom location to docker-compose.yml file and a custom variable SOURCE_DIRECTORY=${PWD}

The docker-compose.yml file has 2 bind volumes:

      - ${PWD}:/home/ubuntu/pwd:ro
      - ${SOURCE_DIRECTORY:-/tmp}:/home/ubuntu/source:ro

First bind resolves correctly $PWD to the current directory, however $SOURCE_DIRECTORY is empty and therefore falls back to /tmp dir. This has worked as expected with docker-compose.

Steps to reproduce the issue:

1. git clone https://gitlab.com/lumnn/docker-compose-env-error.git
2. cd docker-compose-env-error
3. docker compose config

Describe the results you received:

services:
  ubuntu:
    image: ubuntu
    networks:
      default: null
    volumes:
    - type: bind
      source: /home/lumnn/Projects/docker-compose-env-error
      target: /home/ubuntu/pwd
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: /tmp
      target: /home/ubuntu/source
      read_only: true
      bind:
        create_host_path: true

Describe the results you expected:

services:
  ubuntu:
    image: ubuntu
    networks:
      default: null
    volumes:
    - type: bind
      source: /home/lumnn/Projects/docker-compose-env-error
      target: /home/ubuntu/pwd
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: /home/lumnn/Projects/docker-compose-env-error
      target: /home/ubuntu/source
      read_only: true
      bind:
        create_host_path: true

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version 2.0.0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.0)

Server:
 Containers: 42
  Running: 7
  Paused: 0
  Stopped: 35
 Images: 341
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.14.8-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 31.3GiB
 Name: ***
 ID: ***
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: ***
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

Same results I get when using different shells (sh, bash, zsh) and different users (root, or normal account with sudo -E)

[lumnn]

I believe this is fixed now. I don't seem to be able to reproduce the same issue with my latest version of docker and docker compose

$ docker compose version
Docker Compose version 2.2.3

$ docker version
docker version
Client:
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.17.5
 Git commit:        e91ed5707e
 Built:             Mon Dec 13 22:31:40 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.