dockerfile specification for unsetting environment variables.

[sfc-gh-eraigosa]

I want to be able to have a default setting for environment variables in my Dockerfile that cause the env value for a value to not be set when you don't pass --env. Can ENV be improved to support this or give ENV a way to specify an empty string?

case 1 :
ENV foo "" will result in a bash test like if [ -z $ENV ] ; to be false. this is because the value for foo is actually being stored as '""'

Please provide some syntax so that [ -z $FOO ] can be true.

Thanks!

[thaJeztah]

What if you leave out the ENV entirely? Or has the ENV already been defined in the image you're using as FROM? Perhaps these might be interesting for your case; #3465 and #8177

[sfc-gh-eraigosa]

UNSET seems like it could help for the case of inheritance, i like that, but in my dockerfile i want to communicate the intent of a default value that can be overridden at run time with a --env option from whats provided in the Dockerfile. In this case the default I want is an empty string but empty string values don't seem to evaluate correctly in bash.

Will UNSET still list the variables being managed in the Dockerfile at the command line?

[thaJeztah]

Unset will (as proposed, it's not yet merged), basically "remove" the ENV declaration. However, in your case, I'd really just remove the ENV and describe in the README.md that people are able to set an environment variable via -e FOOBAR. If the only reason for adding it to the Dockerfile is to "document" the variable, you could always add a comment line?

If you need more help, perhaps it's better to ask for support on IRC or Google Groups, because the GitHub issue tracker is not the best place for support questions. You can find them on this page; https://docker.com/resources/help/

[sfc-gh-eraigosa]

@thaJeztah Yep, I agree with that approach. I'll close this and look for UNSET feature.

[thaJeztah]

Thanks! And now hope the UNSET feature will be merged soon :)

[oodograss]

+1 for UNSET

[nisaacson]

+1

[lavie]

+2!

[vlad-belogrudov]

+1 sometimes it is mandatory, e.g. when developing container behind proxy

[thaJeztah]

For everyone adding +1's here;

This issue is closed, in favor of #3465, which is still open. There's a pull-request to implement that here; #8177

Please use the other issue to comment, not this one.

[scraperdragon]

@thaJeztah @wenlock

Could we consider reopening this, in light of #3465 being closed?

My specific usecase is needing to set a specific environment variable (DEBIAN_FRONTEND=noninteractive) for a number of RUN statements, and having them all say that is an awful lot of cruft instead of the ability to delete the environment variable.

(Syntaxwise, I imagine ENV !DEBIAN_FRONTEND to be clean, but I don't really care..)

related and discusses specific need: ... ENV DEBIAN_FRONTEND nointeractive #9176 #4032

[duglin]

@scraperdragon I know its not the same thing as unsetting it, but would setting the var to "" help?
e.g. ENV DEBIAN_FRONTEND=

[drj11]

@duglin it may or may not help in this specific case (I have no idea what setting DEBIAN_FRONTEND to the empty string has). But in general, we would like the ability to return the environment to the state we found it. With DEBIAN_FRONTEND not set.

okfn/messytables@166f89a shows the particular case in point

[duglin]

yea I know, was just hoping to might give you some immediate relief

[cdd-aix]

Why not
RUN export DEBIAN_FRONTEND=foo ; apt-get foo; apt-get bar; apt-get quf
?

[yordis]

@thaJeztah does this works with build-args because I need it if this doesn't happen.

P.S: I am confused about it, the build-args are only visible from the build process, right?

[thaJeztah]

@yordis correct, build args are only available during build, however, depending on what unused them for, their value may still end up an image, e.g.

ARG FOO=bar
ENV BAR=$FOO

[ayqazi]

I have a mandatory requirement for UNSET - you see, the silly upstreamers set an environment variable which breaks my builds, and setting it to empty string (ENV FOO=) does not work - it HAS to not be defined for my build to work the way I want without ugly kludges. So......

+1

[haizaar]

Does anyone have an idea is this is going to be implemented anytime soon?

[thaJeztah]

@haizaar see #3465 and #3465 (comment)