How to persist environment variables in ash, the Almquist shell?

Question

How can I get ash to load some environment variables on startup?

Just put them in /etc/profile

/etc/profile is only read for login shells; what about non-login shells, as frequently pop up when working with docker (which uses alpine>busybox>ash)?

A non-login shell will read a file if specified in the environment variable ENV

Great, how can I ensure ENV is set? It is itself an environment variable, and blank by default.

Essentially I’m looking for some overarching config file which ash is guaranteed to read. Preference for the version of ash used by busybox (BusyBox v1.28.4, if you want to be exact). Does such a thing exist? And yes, I know about the ENV directive in docker, which could be used to set $ENV when building a docker image; I'd still like to know if this is possible outside docker.

I have read this and this in an effort to understand.

As a side note, can anyone explain this odd behavior in alpine?

$docker run -it alpine
/ # echo $CHARSET #proof /etc/profile has not run

/ # echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/ # env -i sh -c 'echo $PATH'
/sbin:/usr/sbin:/bin:/usr/bin
/ # echo $ENV

/ #

What’s adding to the PATH compared to the default PATH set for a new shell, when we can show /etc/profile hasn’t? It’s not docker dickery either, the Dockerfile for alpine is deliberately minimal:

FROM scratch
ADD rootfs.tar.xz / #Automatically extracts, and I’m pretty sure that’s all
CMD ["/bin/sh"]

I only mention this because it looks like someone has found a way to persist an environment variable in a non-login shell without the use of $ENV.

I appreciate any information or context, however tangential.

Solution

When you run a docker container, you're running isolated from the calling environment. Variables aren't directly inherited.

We can see a "clean" environment, which we can see by creating a totally minimal container.

e.g. a go program:

package main
import "os"
import "fmt"

func main() {
    for _, e := range os.Environ() {
        fmt.Println(e)
    }
}

We can build this into a tiny container:

FROM scratch
ADD tester /
ENTRYPOINT ["/tester"]

And if we run this:

$ docker run tst
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=e598bf727a26
HOME=/root

These are variables created by the docker engine at runtime.

So when you run .. /bin/sh you're running a non-login shell that just inherits the environment docker creates. Since it's not a login shell, /etc/profile isn't run. /bin/sh will, itself, create some default variables if they do not exist.

$ docker run -it alpine                              
/ # env
HOSTNAME=51667ed06110
SHLVL=1
HOME=/root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/

So there are a number of ways you can do this. Off the top of my head, here's two ideas:

You can pass environment variables on the docker command line with -e.

$ docker run -e myvariable=testing -it alpine /bin/sh
/ # echo $myvariable
testing

You could build your own image based on alpine with ENV commands:

$ cat Dockerfile 
FROM alpine
ENV myothervar=anothertest

$ docker build -t myalpine .
...

$ docker run -it myalpine
/ # echo $myothervar
anothertest

Basically, what you're seeing is the docker run time providing some variables, /bin/sh providing other variables, and isolation from the calling environment.

Comments

[DJV]

Thank you for your answer, but it's not really what I asked. I'm aware that docker has tools you can use to pass environment variables around: >I know about the ENV directive in docker, which could be used to set $ENV when building a docker image; I'd still like to know if this is possible outside docker. What I'd like to know whether this is possible just in the context of the ash shell; also, tangentially, where the PATH variable in docker's alpine image comes from, because it seems like that's where I should look for my solution.

[Stephen Harris]

When you run /bin/sh outside of docker it will inherit the calling environment. So the question is simply "what is the calling environment". With your docker examples, I showed that what you're seeing is docker, itself, creating the calling environment. Ultimately, "how is /bin/sh" being called will determine if $ENV is set or not.

[DJV]

But in a fresh docker container, there is no calling environment; it's the equivalent of a boot, isn't it? The environment must be constructed from internal config files

[Stephen Harris]

No. The docker engine creates a runtime environment.

[DJV]

Ah; the shell received from docker run -it inherits environment variables from the docker engine itself; that makes sense, and explains the behavior of alpine. Now the question is how I can get ash do do my bidding and make sure it reads unrelated variables on startup (which may occur inside docker or without)

[Stephen Harris]

FWIW, I've updated the answer to show the minimal runtime environment by creating a tiny container and not using alpine and /bin/sh at all :-)