I should have opened this as a draft. This is only part of what has been discussed in #4688 because I quickly found differences in how the flags work across different commands.

1. It seems reasonable to me that when there is no A in the host environment, buildah run --env A does nothing to the environment inside the container. This thinking/approach differs from buildah build, however:

2. buildah build --env already handles key-only arguments. When the referenced key does not exist in the environment, it is assigned the empty string within the container.

   buildah/imagebuildah/executor.go

   Lines 515 to 516 in 40dff19

   	value := os.Getenv(key)
   	envLine += fmt.Sprintf(" %q=%q", key, value)

3. buildah config --env already handles key-only arguments. When the referenced key does not exist in the environment or is blank, an error is returned.

   buildah/cmd/buildah/config.go

   Lines 252 to 255 in 40dff19

   	value := os.Getenv(env[0])
   	if value == "" {
   	return fmt.Errorf("setting env %q: no value given", env[0])
   	}

4. buildah config --env already has a special syntax: the - key unsets all variables and the - suffix unsets one variable. Should I proceed with handling two suffixes such that *- means to unset all variables with a certain prefix? 🤔 It almost sounds better to add a buildah config --unsetenv flag such that * unsets all variables, but IIUC ordering sets with unsets would become impossible.

@rhatdan I stopped implementing after (2) for feedback. Which of the three behaviors in (1), (2), and (3) should I use while implementing (1) ? Should I alter the other (either 2 or 3) to match?

/approve

Since I want to get this into release, I am merging. But we could do some minor cleanups and add tests.
/approve
/lgtm
Thanks @cbandy

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cbandy, rhatdan, TomSweeneyRedHat

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Sorry for the delay. I was expecting a response to this question:

@rhatdan I stopped implementing after (2) for feedback. Which of the three behaviors in (1), (2), and (3) should I use while implementing (1) ? Should I alter the other (either 2 or 3) to match?

@flouthoc Could you make these common between the two packages.

Already modified podman to use this from buildah's package here: containers/podman#18130