deactivate fails due to unbound variables when run with set -eu

[MatrixManAtYrService]

A very similar bug was fixed: #1029

The error that I'm getting is this:

venv/bin/activate: line 31: $1: unbound variable

This is the same kind of error, except it exists in deactivate instead of activate

---

To Reproduce

The Setup

In order to insulate against local system differences, this test runs in two containers, only one of which has the problem.

You'll need docker-compose installed, two directories, and three files:

.
├── bad
│   └── Dockerfile
├── docker-compose.yml
└── good
    └── Dockerfile

bad/Dockerfile (this one has the problem)

FROM ubuntu:18.04
RUN apt-get update && apt-get install -y python3-venv
RUN python3 -m venv venv

good/Dockerfile (in this one I've fixed the problem)

FROM ubuntu:18.04
RUN apt-get update && apt-get install -y python3-venv
RUN python3 -m venv venv
RUN sed -i 's/$1/${1:-}/' venv/bin/activate

docker-compose.yml (this runs the test)

version: '3.1'
services:
  good:
    build: good
    command:
      - /bin/bash
      - -c
      - |
        set -eu
        source venv/bin/activate
        deactivate && echo HAPPY
  bad:
    build: bad
    command:
      - /bin/bash
      - -c
      - |
        sleep 5
        set -eu
        source venv/bin/activate
        deactivate && echo HAPPY

The Test

Run: docker-compose up

Output:

Attaching to good_1, bad_1
good_1  | HAPPY
good_1 exited with code 0
bad_1   | venv/bin/activate: line 31: $1: unbound variable
bad_1 exited with code 1

The output above shows that if the $1 is not replaced with ${1:-} (the latter of which tolerates missing parameters), then the call to deactivate fails with an error.

[MatrixManAtYrService]

As a workaround, I create my virtual environments in the Dockerfile like this...

RUN     cd some/dir \
        && python3 -m venv env \
        && bash -c "source env/bin/activate; pip install --upgrade pip; pip install -r requirements.txt" \
        && sed -i 's/$1/${1:-}/' env/bin/activate

...so that at runtime they can be activated like normal.

[gaborbernat]

I think the rewrite branch, release 20.0.0b2 fixed this.