Expand variables in local bash script before passing it to SSH
Clash Royale CLAN TAG#URR8PPP
I am trying to execute a script on a remote host through SSH. The script uses environment variables that are set on the local shell. The variables in the script are not expanded.
ssh user@host 'bash -s' < script.sh
Contents of script.sh
:
#!/bin/bash
docker pull "$IMAGE"
On the remote host this is executed as:
docker pull ""
As indicated by the error output:
Error parsing reference: "" is not a valid repository/tag: repository name must have at least one component
I've tried to use command substitution:
ssh user@host < $(cat script.sh)
Which leads to:
bash: line 95: $(cat script.sh): ambiguous redirect
How can I make the variables in script.sh
expand before passing the commands over SSH?
bash ssh environment-variables
|
show 1 more comment
I am trying to execute a script on a remote host through SSH. The script uses environment variables that are set on the local shell. The variables in the script are not expanded.
ssh user@host 'bash -s' < script.sh
Contents of script.sh
:
#!/bin/bash
docker pull "$IMAGE"
On the remote host this is executed as:
docker pull ""
As indicated by the error output:
Error parsing reference: "" is not a valid repository/tag: repository name must have at least one component
I've tried to use command substitution:
ssh user@host < $(cat script.sh)
Which leads to:
bash: line 95: $(cat script.sh): ambiguous redirect
How can I make the variables in script.sh
expand before passing the commands over SSH?
bash ssh environment-variables
1
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45
|
show 1 more comment
I am trying to execute a script on a remote host through SSH. The script uses environment variables that are set on the local shell. The variables in the script are not expanded.
ssh user@host 'bash -s' < script.sh
Contents of script.sh
:
#!/bin/bash
docker pull "$IMAGE"
On the remote host this is executed as:
docker pull ""
As indicated by the error output:
Error parsing reference: "" is not a valid repository/tag: repository name must have at least one component
I've tried to use command substitution:
ssh user@host < $(cat script.sh)
Which leads to:
bash: line 95: $(cat script.sh): ambiguous redirect
How can I make the variables in script.sh
expand before passing the commands over SSH?
bash ssh environment-variables
I am trying to execute a script on a remote host through SSH. The script uses environment variables that are set on the local shell. The variables in the script are not expanded.
ssh user@host 'bash -s' < script.sh
Contents of script.sh
:
#!/bin/bash
docker pull "$IMAGE"
On the remote host this is executed as:
docker pull ""
As indicated by the error output:
Error parsing reference: "" is not a valid repository/tag: repository name must have at least one component
I've tried to use command substitution:
ssh user@host < $(cat script.sh)
Which leads to:
bash: line 95: $(cat script.sh): ambiguous redirect
How can I make the variables in script.sh
expand before passing the commands over SSH?
bash ssh environment-variables
bash ssh environment-variables
edited Jan 21 at 21:25
Jeff Schaller
41.1k1056131
41.1k1056131
asked Jan 21 at 20:36
ThomasThomas
403
403
1
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45
|
show 1 more comment
1
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45
1
1
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45
|
show 1 more comment
1 Answer
1
active
oldest
votes
You can in principle send environment variables to the remote over SSH, but at least OpenSSH disallows it on the server, and doesn't try to send any from the client. The relevant configuration options are AcceptEnv
in sshd_config
(server) and SendEnv
in ssh_config
(client).
Assuming you can't or don't want to change the configuration there, since you're sending a whole script to the stdin on the remote anyway, you could also stick the variable assignments in front of that script.
We can use export -p
to print out all the exported variables in the current shell, in a format that the remote shell can use to assign them there. Then the remote can process the script as usual, with the variables set.
So with script.sh
containing
echo "$FOO" "$HOSTNAME"
This would export FOO
in the local shell, and then pass the definitions of all exported variables to remote, along with the script itself. The resulting output contains the value of FOO
that was just set.
$ export FOO=abc123
$ (export -p; cat script.sh) | ssh user@remotehost 'bash -s'
FOO: abc123 HOSTNAME: remotehost
(There's a slight problem with Bash here. In normal mode, its export -p
prints out declare
commands instead of the standard export
, and those may not be supported by other shells. So if your local shell is Bash, and you'd start a standard sh
on the remote, you'd get errors.)
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands fromscript.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invokingbash
, would that make a difference?)
– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, thatdocker pull "$IMAGE"
should work just as if with the local value ofIMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.
– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.$(somecmd)
is itself substituted on the command line with the output of `somecmd.
– ilkkachu
Jan 21 at 22:52
add a 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%2f495852%2fexpand-variables-in-local-bash-script-before-passing-it-to-ssh%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
You can in principle send environment variables to the remote over SSH, but at least OpenSSH disallows it on the server, and doesn't try to send any from the client. The relevant configuration options are AcceptEnv
in sshd_config
(server) and SendEnv
in ssh_config
(client).
Assuming you can't or don't want to change the configuration there, since you're sending a whole script to the stdin on the remote anyway, you could also stick the variable assignments in front of that script.
We can use export -p
to print out all the exported variables in the current shell, in a format that the remote shell can use to assign them there. Then the remote can process the script as usual, with the variables set.
So with script.sh
containing
echo "$FOO" "$HOSTNAME"
This would export FOO
in the local shell, and then pass the definitions of all exported variables to remote, along with the script itself. The resulting output contains the value of FOO
that was just set.
$ export FOO=abc123
$ (export -p; cat script.sh) | ssh user@remotehost 'bash -s'
FOO: abc123 HOSTNAME: remotehost
(There's a slight problem with Bash here. In normal mode, its export -p
prints out declare
commands instead of the standard export
, and those may not be supported by other shells. So if your local shell is Bash, and you'd start a standard sh
on the remote, you'd get errors.)
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands fromscript.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invokingbash
, would that make a difference?)
– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, thatdocker pull "$IMAGE"
should work just as if with the local value ofIMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.
– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.$(somecmd)
is itself substituted on the command line with the output of `somecmd.
– ilkkachu
Jan 21 at 22:52
add a comment |
You can in principle send environment variables to the remote over SSH, but at least OpenSSH disallows it on the server, and doesn't try to send any from the client. The relevant configuration options are AcceptEnv
in sshd_config
(server) and SendEnv
in ssh_config
(client).
Assuming you can't or don't want to change the configuration there, since you're sending a whole script to the stdin on the remote anyway, you could also stick the variable assignments in front of that script.
We can use export -p
to print out all the exported variables in the current shell, in a format that the remote shell can use to assign them there. Then the remote can process the script as usual, with the variables set.
So with script.sh
containing
echo "$FOO" "$HOSTNAME"
This would export FOO
in the local shell, and then pass the definitions of all exported variables to remote, along with the script itself. The resulting output contains the value of FOO
that was just set.
$ export FOO=abc123
$ (export -p; cat script.sh) | ssh user@remotehost 'bash -s'
FOO: abc123 HOSTNAME: remotehost
(There's a slight problem with Bash here. In normal mode, its export -p
prints out declare
commands instead of the standard export
, and those may not be supported by other shells. So if your local shell is Bash, and you'd start a standard sh
on the remote, you'd get errors.)
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands fromscript.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invokingbash
, would that make a difference?)
– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, thatdocker pull "$IMAGE"
should work just as if with the local value ofIMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.
– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.$(somecmd)
is itself substituted on the command line with the output of `somecmd.
– ilkkachu
Jan 21 at 22:52
add a comment |
You can in principle send environment variables to the remote over SSH, but at least OpenSSH disallows it on the server, and doesn't try to send any from the client. The relevant configuration options are AcceptEnv
in sshd_config
(server) and SendEnv
in ssh_config
(client).
Assuming you can't or don't want to change the configuration there, since you're sending a whole script to the stdin on the remote anyway, you could also stick the variable assignments in front of that script.
We can use export -p
to print out all the exported variables in the current shell, in a format that the remote shell can use to assign them there. Then the remote can process the script as usual, with the variables set.
So with script.sh
containing
echo "$FOO" "$HOSTNAME"
This would export FOO
in the local shell, and then pass the definitions of all exported variables to remote, along with the script itself. The resulting output contains the value of FOO
that was just set.
$ export FOO=abc123
$ (export -p; cat script.sh) | ssh user@remotehost 'bash -s'
FOO: abc123 HOSTNAME: remotehost
(There's a slight problem with Bash here. In normal mode, its export -p
prints out declare
commands instead of the standard export
, and those may not be supported by other shells. So if your local shell is Bash, and you'd start a standard sh
on the remote, you'd get errors.)
You can in principle send environment variables to the remote over SSH, but at least OpenSSH disallows it on the server, and doesn't try to send any from the client. The relevant configuration options are AcceptEnv
in sshd_config
(server) and SendEnv
in ssh_config
(client).
Assuming you can't or don't want to change the configuration there, since you're sending a whole script to the stdin on the remote anyway, you could also stick the variable assignments in front of that script.
We can use export -p
to print out all the exported variables in the current shell, in a format that the remote shell can use to assign them there. Then the remote can process the script as usual, with the variables set.
So with script.sh
containing
echo "$FOO" "$HOSTNAME"
This would export FOO
in the local shell, and then pass the definitions of all exported variables to remote, along with the script itself. The resulting output contains the value of FOO
that was just set.
$ export FOO=abc123
$ (export -p; cat script.sh) | ssh user@remotehost 'bash -s'
FOO: abc123 HOSTNAME: remotehost
(There's a slight problem with Bash here. In normal mode, its export -p
prints out declare
commands instead of the standard export
, and those may not be supported by other shells. So if your local shell is Bash, and you'd start a standard sh
on the remote, you'd get errors.)
edited Jan 21 at 22:44
answered Jan 21 at 21:46
ilkkachuilkkachu
58.3k890164
58.3k890164
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands fromscript.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invokingbash
, would that make a difference?)
– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, thatdocker pull "$IMAGE"
should work just as if with the local value ofIMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.
– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.$(somecmd)
is itself substituted on the command line with the output of `somecmd.
– ilkkachu
Jan 21 at 22:52
add a comment |
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands fromscript.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invokingbash
, would that make a difference?)
– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, thatdocker pull "$IMAGE"
should work just as if with the local value ofIMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.
– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.$(somecmd)
is itself substituted on the command line with the output of `somecmd.
– ilkkachu
Jan 21 at 22:52
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands from
script.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invoking bash
, would that make a difference?)– Thomas
Jan 21 at 22:08
Thank you for the explanation, however, my intention is not to send the env vars to the remote host, they should remain local. What I am trying to send to the remote host are the commands from
script.sh
with the vars already expanded. Your second suggestion seems interesting, could we shape that in a way to achieve the aformentioned goal? (I already tried command substitution, but without invoking bash
, would that make a difference?)– Thomas
Jan 21 at 22:08
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, that
docker pull "$IMAGE"
should work just as if with the local value of IMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.– ilkkachu
Jan 21 at 22:14
@Thomas, mhh, does it matter which way you do it? If I didn't get this too wrong, that
docker pull "$IMAGE"
should work just as if with the local value of IMAGE
if the export definitions are pushed to the remote. Pre-expanding the variables within the script text would be really problematic in the general case. Any quotes and other shell syntax characters within the values would take effect during parsing, which they don't if the variables are kept just as variables.– ilkkachu
Jan 21 at 22:14
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
Sorry, I misunderstood the concept. I've been experimenting with your solution and it seems to do exactly what I want, thank you (process subtitution is a new one to me). Guess the frustration of the past several hours got to me, haha. Marked as best answer -- thanks again!
– Thomas
Jan 21 at 22:38
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.
$(somecmd)
is itself substituted on the command line with the output of `somecmd.– ilkkachu
Jan 21 at 22:52
@Thomas, ah ok, good. I'm sorry I wasn't able to explain the idea better. Process substitution isn't really the point, mentioning it might just have been confusing here. It's mostly like a generalized replacement for pipes (see mywiki.wooledge.org/ProcessSubstitution or related questions here). Neither that or command substitution do anything about the contents of the files. I think the names refer to the fact that e.g.
$(somecmd)
is itself substituted on the command line with the output of `somecmd.– ilkkachu
Jan 21 at 22:52
add a 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%2f495852%2fexpand-variables-in-local-bash-script-before-passing-it-to-ssh%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
1
Do you just need $IMAGE, or are there others that aren't apparent?
– Jeff Schaller
Jan 21 at 20:38
There are others as well
– Thomas
Jan 21 at 20:38
Are you able to enumerate them, or do you prefer to send every environmental variable over?
– Jeff Schaller
Jan 21 at 20:39
The environment variables must all remain local, I'm not entirely sure what you mean by enumerating them in this context
– Thomas
Jan 21 at 20:41
If there's just IMAGE, FOO, and BAR, that's one case; if there are dozens of others, that's the other case.
– Jeff Schaller
Jan 21 at 20:45