Need tmux to inherit and pass on environment to a subshell

[Jesse Molina]

I have a problem.

I have a bash script which calls tmux to create new sessions, in which
it runs another application or script.

This first bash script has a number of environmental variables which I
need to exist in the new-session env to get passed on to the
application/script in which the new session starts.

What is the best way to do this?

These variable values are dynamic.

There are a number of ugly and bad ways I could work around this, and
none of them sound good.

As far as I can tell, options can't be set on a tmux session until after
it has been created, which defeats the purpose. How do you start a new
session with a defined env? Apparently you don't be cause it can't.

[Balazs Kezes]

Post by Jesse Molina
This first bash script has a number of environmental variables which I
need to exist in the new-session env to get passed on to the
application/script in which the new session starts.

You can try passing the current environment to the session's first
process on its command line. Try this (beware: this is a bit unsafe this
way, you'll need to sanitize this command, this is just a
demonstration):

tmux new-session "env $(env | tr '\n' ' ') bash"

After the new session already exists, you can script around the
set-environment command in tmux.

[Jesse Molina]

This post might be inappropriate. Click to display it.

[Jesse Molina]

I think, ultimately, my problem comes down to not being able to
configure tmux session or window options during initialization except
from a configuration file via -f.

The user can't specify options to a new-session or new-window, within
the command itself, until after it has been created, which is too late.

set-option can't be used until after the shell-command has been executed.

My best choices at this time seem to be a "env $VARS command" as the
shell-command, or write a custom tmux config and source it with -f on
the fly.

It's not as if I can modify the program I am running to not take it's
configuration from the environment.

Please disagree with me if someone sees a better solution here that I don't.

Post by Jesse Molina
Thanks for the suggestion. This was pretty close to what I was already
doing as a hack.
I have a lot of variables, and many of them have spaces. printenv/env
doesn't output quoted values, so I have to alter the output further from
there and generate a huge command list.
I don't understand why tmux is a brick wall between these processes when
the need to do this seems really obvious. Environmental variables are
right up there with stdin. It's like not being able to pass arguments to
a command.
It's easy to find a large number of user problems with both tmux and
screen where tmux/screen is being a brick wall between processes. People
are writing their input to text files and pipes to read them into the
https://superuser.com/questions/105954/updating-screen-session-environment-variables-to-reflect-new-graphical-login
Is this an obvious badly-needed feature, or am I not taking something
into consideration?
I would suggest a command option to new-session/new-window where the
user can list a series of vars which tmux will pass on to the new
process. tmux already does this with certain special variables.
I've been playing around with set-environment and set-option
update-environment too. set-envrionment kinda works, but is a huge pain
since it only accepts a single variable per invocation; I'll have to
while loop it. It also doesn't solve the problem of the environment
being in place when the command is executed. I either have to make my
command wait for the env to be ready, or some other nonsense.
update-environment seems to be pretty worthless. The man page says it
can be used for "when a new session is created", but I assume that means
I have to use it against the global settings *before* I create the new
session, since I can't issue commands against a session that doesn't yet
exist and I can't issue these options to the new session before the
command is executed.

Post by Balazs Kezes

Post by Jesse Molina
This first bash script has a number of environmental variables which I
need to exist in the new-session env to get passed on to the
application/script in which the new session starts.

You can try passing the current environment to the session's first
process on its command line. Try this (beware: this is a bit unsafe this
way, you'll need to sanitize this command, this is just a
tmux new-session "env $(env | tr '\n' ' ') bash"
After the new session already exists, you can script around the
set-environment command in tmux.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
tmux-users mailing list
https://lists.sourceforge.net/lists/listinfo/tmux-users

[Jesse Molina]

Because a number of my vars have spaces or special characters in them, I
have to do this nonsense because env output doesn't quote the values.

ONE=1
TWO="2 2"
THREE="3 -3 +3 =3"
EXPORT_VARS="ONE TWO THREE"

echo $(for VAR in $EXPORT_VARS ; do echo "${VAR}=\"${!VAR}\"" ; done) |
tr '\n' ' '

Which is a good example of bash indirect parameter expansion.


So, the line below turns into this:

tmux new-session "env $(echo $(for VAR in $EXPORT_VARS ; do echo
"${VAR}=\"${!VAR}\"" ; done) | tr '\n' ' ') bash"

And ugly as it is, it works for me. I don't like it though. I'd much
rather have a tmux option like this:

tmux new-session -setenv "$EXPORT_VARS" "bash"

Post by Balazs Kezes

Post by Jesse Molina
This first bash script has a number of environmental variables which I
need to exist in the new-session env to get passed on to the
application/script in which the new session starts.

You can try passing the current environment to the session's first
process on its command line. Try this (beware: this is a bit unsafe this
way, you'll need to sanitize this command, this is just a
tmux new-session "env $(env | tr '\n' ' ') bash"
After the new session already exists, you can script around the
set-environment command in tmux.

[Balazs Kezes]

Post by Jesse Molina
Because a number of my vars have spaces or special characters in them,
I have to do this nonsense because env output doesn't quote the
values.

Yeah, bash might not be the best thing to do this. You could for
instance create a custom "env" command. This could read the environment
variables from a file instead from the argument list where it can be
very flaky. I've attached an example of such program. Use it like this:

env -0 >/tmp/env && tmux new-session "modify_env /tmp/env bash"

Here, the attached modify_env reads the null separated list of
environment variables, updates it's current environment (it won't
overwrite already existing vars), deletes the env file (why would I need
it anymore?) and then just executes the rest of the command line.

Would something like that work for the moment? You could even hardcode
the filename to make the usage shorter.

Post by Jesse Molina
tmux new-session -setenv "$EXPORT_VARS" "bash"

So you are proposing a new flag to new-session/new-window/split-window
with which we can mark some variables to copy from the current
environment to the newly created process? This sounds like it could be
useful. But this is something for the tmux devs to decide, I'm just a
lurker here. :)

[Nicholas Marriott]

Create the session, set the options, create a new window, kill window 0 then move the new window to 0 (or movew -k or movew -r).

-------- Original message --------
From: Jesse Molina <***@opendreams.net>
Date: 02/06/2014 03:23 (GMT+00:00)
To: tmux-***@lists.sourceforge.net
Subject: Re: Need tmux to inherit and pass on environment to a subshell


I think, ultimately, my problem comes down to not being able to
configure tmux session or window options during initialization except
from a configuration file via -f.

The user can't specify options to a new-session or new-window, within
the command itself, until after it has been created, which is too late.

set-option can't be used until after the shell-command has been executed.

My best choices at this time seem to be a "env $VARS command" as the
shell-command, or write a custom tmux config and source it with -f on
the fly.

It's not as if I can modify the program I am running to not take it's
configuration from the environment.

Please disagree with me if someone sees a better solution here that I don't.

Post by Jesse Molina
Thanks for the suggestion. This was pretty close to what I was already
doing as a hack.
I have a lot of variables, and many of them have spaces. printenv/env
doesn't output quoted values, so I have to alter the output further from
there and generate a huge command list.
I don't understand why tmux is a brick wall between these processes when
the need to do this seems really obvious. Environmental variables are
right up there with stdin. It's like not being able to pass arguments to
a command.
It's easy to find a large number of user problems with both tmux and
screen where tmux/screen is being a brick wall between processes. People
are writing their input to text files and pipes to read them into the
https://superuser.com/questions/105954/updating-screen-session-environment-variables-to-reflect-new-graphical-login
Is this an obvious badly-needed feature, or am I not taking something
into consideration?
I would suggest a command option to new-session/new-window where the
user can list a series of vars which tmux will pass on to the new
process.  tmux already does this with certain special variables.
I'

[Jesse Molina]

Thanks for your suggestion. I think that was my second-best option, but
it's still more complicated than using env. It would require iterating
over the "set-environment" command a number of times since it only takes
a single var per invocation.

Post by Nicholas Marriott
Create the session, set the options, create a new window, kill window
0 then move the new window to 0 (or movew -k or movew -r).
-------- Original message --------
Date: 02/06/2014 03:23 (GMT+00:00)
Subject: Re: Need tmux to inherit and pass on environment to a subshell
I think, ultimately, my problem comes down to not being able to
configure tmux session or window options during initialization except
from a configuration file via -f.
The user can't specify options to a new-session or new-window, within
the command itself, until after it has been created, which is too late.
set-option can't be used until after the shell-command has been executed.
My best choices at this time seem to be a "env $VARS command" as the
shell-command, or write a custom tmux config and source it with -f on
the fly.
It's not as if I can modify the program I am running to not take it's
configuration from the environment.
Please disagree with me if someone sees a better solution here that I don't.

Post by Jesse Molina
Thanks for the suggestion. This was pretty close to what I was already
doing as a hack.
I have a lot of variables, and many of them have spaces. printenv/env
doesn't output quoted values, so I have to alter the output further from
there and generate a huge command list.
I don't understand why tmux is a brick wall between these processes when
the need to do this seems really obvious. Environmental variables are
right up there with stdin. It's like not being able to pass arguments to
a command.
It's easy to find a large number of user problems with both tmux and
screen where tmux/screen is being a brick wall between processes. People
are writing their input to text files and pipes to read them into the

https://superuser.com/questions/105954/updating-screen-session-environment-variables-to-reflect-new-graphical-login

Post by Jesse Molina
Is this an obvious badly-needed feature, or am I not taking something
into consideration?
I would suggest a command option to new-session/new-window where the
user can list a series of vars which tmux will pass on to the new
process. tmux already does this with certain special variables.
I'