ssh ignores variables in profile files
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
1
down vote
favorite
Apologies for this vague question in advance, but I don't know how to narrow this down.
I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014
as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.
Now, ssh works as expected, except all variables that I define in .bashrc
or .profile
are ignored (yes, I'm aware that .profile
sources .bashrc
). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.
Local variables exist on both the local and the remote machine, but when I ssh
into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
gives no output.
What could be the reason for this behavior?
EDIT
I did not have .bash_profile
or .bash_login
on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo
to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
.
bash ssh environment-variables
add a comment |Â
up vote
1
down vote
favorite
Apologies for this vague question in advance, but I don't know how to narrow this down.
I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014
as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.
Now, ssh works as expected, except all variables that I define in .bashrc
or .profile
are ignored (yes, I'm aware that .profile
sources .bashrc
). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.
Local variables exist on both the local and the remote machine, but when I ssh
into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
gives no output.
What could be the reason for this behavior?
EDIT
I did not have .bash_profile
or .bash_login
on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo
to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
.
bash ssh environment-variables
Do you have a~/.bash_profile
or~/.bash_login
on the remote machine?
â steeldriver
Mar 21 at 22:05
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to$LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if$LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
â Markus Heller
Mar 21 at 22:43
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Apologies for this vague question in advance, but I don't know how to narrow this down.
I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014
as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.
Now, ssh works as expected, except all variables that I define in .bashrc
or .profile
are ignored (yes, I'm aware that .profile
sources .bashrc
). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.
Local variables exist on both the local and the remote machine, but when I ssh
into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
gives no output.
What could be the reason for this behavior?
EDIT
I did not have .bash_profile
or .bash_login
on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo
to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
.
bash ssh environment-variables
Apologies for this vague question in advance, but I don't know how to narrow this down.
I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014
as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.
Now, ssh works as expected, except all variables that I define in .bashrc
or .profile
are ignored (yes, I'm aware that .profile
sources .bashrc
). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.
Local variables exist on both the local and the remote machine, but when I ssh
into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
gives no output.
What could be the reason for this behavior?
EDIT
I did not have .bash_profile
or .bash_login
on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo
to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'
.
bash ssh environment-variables
bash ssh environment-variables
edited Mar 21 at 22:23
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
![](https://i.stack.imgur.com/eVuAv.png?s=32&g=1)
wjandrea
7,19342255
7,19342255
asked Mar 21 at 21:46
Markus Heller
83
83
Do you have a~/.bash_profile
or~/.bash_login
on the remote machine?
â steeldriver
Mar 21 at 22:05
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to$LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if$LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
â Markus Heller
Mar 21 at 22:43
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04
add a comment |Â
Do you have a~/.bash_profile
or~/.bash_login
on the remote machine?
â steeldriver
Mar 21 at 22:05
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to$LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if$LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
â Markus Heller
Mar 21 at 22:43
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04
Do you have a
~/.bash_profile
or ~/.bash_login
on the remote machine?â steeldriver
Mar 21 at 22:05
Do you have a
~/.bash_profile
or ~/.bash_login
on the remote machine?â steeldriver
Mar 21 at 22:05
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize
$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?â Markus Heller
Mar 21 at 22:43
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize
$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?â Markus Heller
Mar 21 at 22:43
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Bash reads .profile
* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i
option, and non-login unless you give the -l
option, etc. Neither of this is usually possible when executing commands via SSH.
Bash does read .bashrc
when run non-interactively by SSH. However, the default .bashrc
includes a check for interactive use:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
So effectively, no variable set in .profile
or .bashrc
is available when you do ssh foo some-command
. You can put the variables in .bashrc
before the check for interactive execution. For example:
$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...
The echo foo
was executed. If I had export foo=bar
, then foo
would have showed up in the env
output.
* with suitable caveats about the presence of files like .bash_profile
, etc.
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:[ -z "$PS1" ] && return
.
â Markus Heller
Mar 22 at 17:52
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Bash reads .profile
* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i
option, and non-login unless you give the -l
option, etc. Neither of this is usually possible when executing commands via SSH.
Bash does read .bashrc
when run non-interactively by SSH. However, the default .bashrc
includes a check for interactive use:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
So effectively, no variable set in .profile
or .bashrc
is available when you do ssh foo some-command
. You can put the variables in .bashrc
before the check for interactive execution. For example:
$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...
The echo foo
was executed. If I had export foo=bar
, then foo
would have showed up in the env
output.
* with suitable caveats about the presence of files like .bash_profile
, etc.
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:[ -z "$PS1" ] && return
.
â Markus Heller
Mar 22 at 17:52
add a comment |Â
up vote
1
down vote
accepted
Bash reads .profile
* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i
option, and non-login unless you give the -l
option, etc. Neither of this is usually possible when executing commands via SSH.
Bash does read .bashrc
when run non-interactively by SSH. However, the default .bashrc
includes a check for interactive use:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
So effectively, no variable set in .profile
or .bashrc
is available when you do ssh foo some-command
. You can put the variables in .bashrc
before the check for interactive execution. For example:
$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...
The echo foo
was executed. If I had export foo=bar
, then foo
would have showed up in the env
output.
* with suitable caveats about the presence of files like .bash_profile
, etc.
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:[ -z "$PS1" ] && return
.
â Markus Heller
Mar 22 at 17:52
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Bash reads .profile
* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i
option, and non-login unless you give the -l
option, etc. Neither of this is usually possible when executing commands via SSH.
Bash does read .bashrc
when run non-interactively by SSH. However, the default .bashrc
includes a check for interactive use:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
So effectively, no variable set in .profile
or .bashrc
is available when you do ssh foo some-command
. You can put the variables in .bashrc
before the check for interactive execution. For example:
$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...
The echo foo
was executed. If I had export foo=bar
, then foo
would have showed up in the env
output.
* with suitable caveats about the presence of files like .bash_profile
, etc.
Bash reads .profile
* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i
option, and non-login unless you give the -l
option, etc. Neither of this is usually possible when executing commands via SSH.
Bash does read .bashrc
when run non-interactively by SSH. However, the default .bashrc
includes a check for interactive use:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
So effectively, no variable set in .profile
or .bashrc
is available when you do ssh foo some-command
. You can put the variables in .bashrc
before the check for interactive execution. For example:
$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...
The echo foo
was executed. If I had export foo=bar
, then foo
would have showed up in the env
output.
* with suitable caveats about the presence of files like .bash_profile
, etc.
answered Mar 22 at 1:45
muru
130k19273463
130k19273463
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:[ -z "$PS1" ] && return
.
â Markus Heller
Mar 22 at 17:52
add a comment |Â
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:[ -z "$PS1" ] && return
.
â Markus Heller
Mar 22 at 17:52
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:
[ -z "$PS1" ] && return
.â Markus Heller
Mar 22 at 17:52
This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this:
[ -z "$PS1" ] && return
.â Markus Heller
Mar 22 at 17:52
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1018072%2fssh-ignores-variables-in-profile-files%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
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
Do you have a
~/.bash_profile
or~/.bash_login
on the remote machine?â steeldriver
Mar 21 at 22:05
OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
â steeldriver
Mar 21 at 22:35
Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize
$LOCAL_VARIABLE
so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to$LOCAL_VARIABLE
(which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if$LOCAL_VARIABLE
is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?â Markus Heller
Mar 21 at 22:43
Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
â steeldriver
Mar 21 at 23:04