How to persist environment variables in ash, the Almquist shell?
Clash Royale CLAN TAG#URR8PPP
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.
environment-variables path docker profile ash
add a comment |
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.
environment-variables path docker profile ash
add a comment |
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.
environment-variables path docker profile ash
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.
environment-variables path docker profile ash
environment-variables path docker profile ash
edited Feb 27 at 23:49
Stephen Harris
26.9k35181
26.9k35181
asked Feb 27 at 22:21
DJVDJV
61
61
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
|
show 1 more comment
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503432%2fhow-to-persist-environment-variables-in-ash-the-almquist-shell%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
|
show 1 more comment
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.
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
|
show 1 more comment
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.
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.
edited Feb 28 at 0:20
answered Feb 27 at 23:43
Stephen HarrisStephen Harris
26.9k35181
26.9k35181
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
|
show 1 more comment
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
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.
– DJV
Feb 28 at 0:01
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.
– DJV
Feb 28 at 0:01
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.
– Stephen Harris
Feb 28 at 0:02
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.
– Stephen Harris
Feb 28 at 0:02
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
– DJV
Feb 28 at 0:04
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
– DJV
Feb 28 at 0:04
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
No. The docker engine creates a runtime environment.
– Stephen Harris
Feb 28 at 0:05
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)
– DJV
Feb 28 at 0:08
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)
– DJV
Feb 28 at 0:08
|
show 1 more comment
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503432%2fhow-to-persist-environment-variables-in-ash-the-almquist-shell%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown