export

export

[Ray Andrews]

When I export a variable it is only available in subsequent shells in 
the same xterm. Can I make it export globally?  Or is the issue somehow 
related to the xterm itself?

Re: export

[Eric Cook]

On 11/25/2014 07:57 PM, Ray Andrews wrote:
> When I export a variable it is only available in subsequent shells in
> the same xterm. Can I make it export globally?  Or is the issue
> somehow related to the xterm itself?
The environment is a one way copy from parent process to child, you
can't propagate it the other direction through normal means.

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

It's a function of the operating system. All UNIX like operating systems
use an inheritance model. That is, when a new process is spawned it gets a
copy of the parent environment or one specially crafted by the parent for
the child process. The environment is copied into the address space of the
process (almost always near the top of the stack before the main() function
is invoked). This means each process has its own, private, set of
environment variables. This makes it infeasible for one process to modify
the environment variables of another process.  It also means, obviously,
there is no "global" set of environment variables. This book is the best
one for understanding why things work the way they do on UNIX like
operating systems: http://www.apuebook.com/apue3e.html

Try typing "man execle" at a shell prompt to read about the API that zsh
uses to start a new process and pass it an environment. That command may or
may not work depending on the packages you've installed on your system.

I've programmed on at least two operating systems which had a totally
different model for the equivalent of environment variables where what
you're trying to do was possible. But those operating systems were swept
into the dustbin of history several decades ago.

On Tue, Nov 25, 2014 at 4:57 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> When I export a variable it is only available in subsequent shells in the
> same xterm. Can I make it export globally?  Or is the issue somehow related
> to the xterm itself?
>



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Bart Schaefer]

On Nov 25,  4:57pm, Ray Andrews wrote:
} Subject: export
}
} When I export a variable it is only available in subsequent shells in 
} the same xterm. Can I make it export globally?

As others have explained, this is part of the design of the unix process
model.  With a shell, however, you can fake it:

http://unix.stackexchange.com/questions/137077/serialize-shell-variable-in-bash-or-zsh

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

If by "fake it" you mean cooperative processes that implement a protocol
for exchanging environment variables then, yes, you can achieve the result
desired by Ray. However I think that everyone trying to achieve this result
wants to do so without having to implement a new data exchange protocol in
every program. If they were willing to implement a private data exchange
protocol they wouldn't be asking this question. :-)

On Tue, Nov 25, 2014 at 8:32 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Nov 25,  4:57pm, Ray Andrews wrote:
> } Subject: export
> }
> } When I export a variable it is only available in subsequent shells in
> } the same xterm. Can I make it export globally?
>
> As others have explained, this is part of the design of the unix process
> model.  With a shell, however, you can fake it:
>
>
> http://unix.stackexchange.com/questions/137077/serialize-shell-variable-in-bash-or-zsh
>



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Ray Andrews]

On 11/25/2014 08:32 PM, Bart Schaefer wrote:
> On Nov 25,  4:57pm, Ray Andrews wrote:
> } Subject: export
> }
> } When I export a variable it is only available in subsequent shells in
> } the same xterm. Can I make it export globally?
>

You guys don't understand what I'm asking.  I know I can't pass
variables 'backwards' (except via a file), but when I export, the
variable will be available  in *subsequent* shells but only in the
same xterm:

	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ export trash=TRASH

	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ zsh

	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
	TRASH

... export does what it should do, but *only* in the same xterm.
If I now go to another xterm, $trash is not set:

	pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ zsh

	pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ echo $trash

Re: export

[Ray Andrews]

On 11/25/2014 08:54 PM, Kurtis Rader wrote:
> If by "fake it" you mean cooperative processes that implement a protocol
> for exchanging environment variables then, yes, you can achieve the result
> desired by Ray. However I think that everyone trying to achieve this result
> wants to do so without having to implement a new data exchange protocol in
> every program. If they were willing to implement a private data exchange
> protocol they wouldn't be asking this question. :-)

As it is, I pass some variables between running shells all the time in 
'preexec()'.
Specifically every shell in every xterm knows the current directory of 
every
other so I can do: " cp foo $t4 " with ' $t4 ' being the current dir in 
xterm #4.

But that's not the problem, I just want 'export' to work between xterms 
if possible.
It's hardly important tho.

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

No, it is not possible on UNIX like operating systems (which include
Microsoft Windows) for "export" to "work between" xterms or any other set
of programs. When you execute the "export" or "typeset -x" command in a zsh
process it can only modify the environment for that zsh process.

On Tue, Nov 25, 2014 at 9:16 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 11/25/2014 08:54 PM, Kurtis Rader wrote:
>
>> If by "fake it" you mean cooperative processes that implement a protocol
>> for exchanging environment variables then, yes, you can achieve the result
>> desired by Ray. However I think that everyone trying to achieve this
>> result
>> wants to do so without having to implement a new data exchange protocol in
>> every program. If they were willing to implement a private data exchange
>> protocol they wouldn't be asking this question. :-)
>>
>
> As it is, I pass some variables between running shells all the time in
> 'preexec()'.
> Specifically every shell in every xterm knows the current directory of
> every
> other so I can do: " cp foo $t4 " with ' $t4 ' being the current dir in
> xterm #4.
>
> But that's not the problem, I just want 'export' to work between xterms if
> possible.
> It's hardly important tho.
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Each process gets a private copy of the environment provided by its parent.
An xterm is just a process. In your example you have this chain of
processes (parent => child):

  xterm => zsh => zsh

There is no way for an arbitrary zsh process to affect the environment of
an arbitrary xterm process.

On Tue, Nov 25, 2014 at 9:07 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 11/25/2014 08:32 PM, Bart Schaefer wrote:
>
>> On Nov 25,  4:57pm, Ray Andrews wrote:
>> } Subject: export
>> }
>> } When I export a variable it is only available in subsequent shells in
>> } the same xterm. Can I make it export globally?
>>
>>
> You guys don't understand what I'm asking.  I know I can't pass
> variables 'backwards' (except via a file), but when I export, the
> variable will be available  in *subsequent* shells but only in the
> same xterm:
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ export trash=TRASH
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ zsh
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>         TRASH
>
> ... export does what it should do, but *only* in the same xterm.
> If I now go to another xterm, $trash is not set:
>
>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ zsh
>
>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ echo $trash
>
>
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Павлов Николай Александрович]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On November 26, 2014 8:07:19 AM EAT, Ray Andrews <rayandrews@eastlink.ca> wrote:
>On 11/25/2014 08:32 PM, Bart Schaefer wrote:
>> On Nov 25,  4:57pm, Ray Andrews wrote:
>> } Subject: export
>> }
>> } When I export a variable it is only available in subsequent shells
>in
>> } the same xterm. Can I make it export globally?
>>
>
>You guys don't understand what I'm asking.  I know I can't pass
>variables 'backwards' (except via a file), but when I export, the
>variable will be available  in *subsequent* shells but only in the
>same xterm:
>
>	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ export trash=TRASH
>
>	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ zsh
>
>	pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>	TRASH
>
>... export does what it should do, but *only* in the same xterm.
>If I now go to another xterm, $trash is not set:
>
>	pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ zsh
>
>	pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ echo $trash

In another xterm there is different zsh process. Environment for the new shells is inherited from the parent. It absolutely irrelevant which existing process you may want to modify environment in. The only thing that was added is that with this requirements you may take this environment once at startup (e.g. in $HOME/.zshenv) and not in some hook like precmd.

And it does not do what it does "in xterm". It only does thing for the current shell process and next process run from the shell only inherits the environment. Given the existence of screen and dtach (not tmux: here environment is inherited from the server) you may migrate shells between terminal emulators. Or start screen in one and attach in its neighbour: after some scripting this may be a solution. Tmux may also be a solution: if you export in your shell and then repeat "export" using "tmux set-environment -g" then exported variable will appear in all new tmux instances.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJUdWoyMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIns4EADOYIUvpa4jnzqL3EKkEw5A
nqOk2l8ytAgiK9Y4Nxd/9NTJMJ41H4sFJO/0bE3RARhx5eeVcItLgFnLaRKm5AyR
ghDeiRJgehcrph+gQFqKROWJ4jLFG62HuWDXlkqWuVcpLZHf9JE//nMQFl3RLjc1
gW4szARFQUhGb4E0bQhg7T+wZzA2KF1tb8Nhj1pt23/LvyZzot3Hnj5TQvvogZ2d
Ajajk42e/Z8rRvwuZDc8u1uiSwwhM9NoFXbaQEUDO+ddpS4CQW1cyxeYa9u7y2S5
jzV09STtQb4V6hBhPKS5JqZiCGYwjS4k/yGvWPnyck6WIw6UhPuPMhmHjw1AGYOt
tPrzMu3h6H2XAPVh6HvtPhkqvPTvUO9g3B6aJDYjXh1YvDMnPjOIgUL/naSyML5E
qCzoP9oOtaeqkyxkLidBKnrxW2/1/ExwjAg9gj7244zOxXRDd+L4o3S6bG+4Z1iR
w+T4fltR0v7e3Ad3lbM0nERl8UaWhbQMhvIL7d8WCA/dSbdxuee3dATYk+y/Ucaw
uLItZXiyPj2jBowoOuNONkjOqgqaUI18Uu7QTMaUBBs4fXiIPbJziqh5W8/P629A
CZwME1Cwq8tgPn1ggsnkG6o4X27u1w9WqBSmarAGh5tBb+CGXdGtl/D/DwerJDsb
omg7NC9P5XLcLXmSGL9uRw==
=+xrg
-----END PGP SIGNATURE-----

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

In general a process, whether it is a zsh or other program, cannot affect
the environment of any other program. It can only provide the initial state
for a new program that it executes. That is what is happening in your
example. You are interacting with a zsh process spawned by a xterm. In that
zsh process you modify its environment. You then spawn a new shell which
inherits a private copy of that environment.

There is no way to modify the private copy a given process has of its
environment.

On Tue, Nov 25, 2014 at 9:43 PM, Kurtis Rader <krader@skepticism.us> wrote:

> Each process gets a private copy of the environment provided by its
> parent. An xterm is just a process. In your example you have this chain of
> processes (parent => child):
>
>   xterm => zsh => zsh
>
> There is no way for an arbitrary zsh process to affect the environment of
> an arbitrary xterm process.
>
> On Tue, Nov 25, 2014 at 9:07 PM, Ray Andrews <rayandrews@eastlink.ca>
> wrote:
>
>> On 11/25/2014 08:32 PM, Bart Schaefer wrote:
>>
>>> On Nov 25,  4:57pm, Ray Andrews wrote:
>>> } Subject: export
>>> }
>>> } When I export a variable it is only available in subsequent shells in
>>> } the same xterm. Can I make it export globally?
>>>
>>>
>> You guys don't understand what I'm asking.  I know I can't pass
>> variables 'backwards' (except via a file), but when I export, the
>> variable will be available  in *subsequent* shells but only in the
>> same xterm:
>>
>>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ export trash=TRASH
>>
>>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ zsh
>>
>>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>>         TRASH
>>
>> ... export does what it should do, but *only* in the same xterm.
>> If I now go to another xterm, $trash is not set:
>>
>>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ zsh
>>
>>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ echo
>> $trash
>>
>>
>>
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

FWIW, almost everyone, including me, has asked this question. That is,
we've wished there was someway for a process to asynchronously modify the
environment variables of another, arbitrary, process. There are good
reasons from both a security as well as predicable execution model why that
is a bad idea and therefore not allowed.

On Tue, Nov 25, 2014 at 9:07 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 11/25/2014 08:32 PM, Bart Schaefer wrote:
>
>> On Nov 25,  4:57pm, Ray Andrews wrote:
>> } Subject: export
>> }
>> } When I export a variable it is only available in subsequent shells in
>> } the same xterm. Can I make it export globally?
>>
>>
> You guys don't understand what I'm asking.  I know I can't pass
> variables 'backwards' (except via a file), but when I export, the
> variable will be available  in *subsequent* shells but only in the
> same xterm:
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ export trash=TRASH
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ zsh
>
>         pts/2 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>         TRASH
>
> ... export does what it should do, but *only* in the same xterm.
> If I now go to another xterm, $trash is not set:
>
>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ zsh
>
>         pts/9 HP-y5--5-Debian1 root /boot/Clone/y8--5-Debian2 $ echo $trash
>
>
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: export

[Stephane Chazelas]

2014-11-25 20:54:39 -0800, Kurtis Rader:
> If by "fake it" you mean cooperative processes that implement a protocol
> for exchanging environment variables then, yes, you can achieve the result
> desired by Ray. However I think that everyone trying to achieve this result
> wants to do so without having to implement a new data exchange protocol in
> every program.
[...]

FYI, the "fish" shell does that.

set -U universal its value

and that $universal variable (here an array) becomes available
in all the fish shells (interactive or not) by the same user on
the machine (with all the security implications it entails).

-- 
Stephane

Re: export

[Peter Stephenson]

On Tue, 25 Nov 2014 16:57:24 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> When I export a variable it is only available in subsequent shells in 
> the same xterm. Can I make it export globally?  Or is the issue somehow 
> related to the xterm itself?

If you simply want to ensure at boot it's set for all non-privileged
users you can use the /etc/environment file (depending on OS).

pws

Re: export

[Clint Hepner]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Wed, Nov 26, 2014 at 2:18 AM, Stephane Chazelas <
stephane.chazelas@gmail.com> wrote:

> 2014-11-25 20:54:39 -0800, Kurtis Rader:
> > If by "fake it" you mean cooperative processes that implement a protocol
> > for exchanging environment variables then, yes, you can achieve the
> result
> > desired by Ray. However I think that everyone trying to achieve this
> result
> > wants to do so without having to implement a new data exchange protocol
> in
> > every program.
> [...]
>
> FYI, the "fish" shell does that.
>
> set -U universal its value
>
> and that $universal variable (here an array) becomes available
> in all the fish shells (interactive or not) by the same user on
> the machine (with all the security implications it entails).
>
>
Note that fish implements this in a manner similar to one mentioned earlier
in this thread: it uses a separate process that acts as a variable server.
When fish tries to look up a variable, and fails to find it in either the
local or global scope, it contacts the server to see if the variable exists
at the "universal" scope.

Re: export

[Ray Andrews]

All:

> Each process gets a private copy of the environment provided by its
> parent. An xterm is just a process. In your example you have this chain
> of processes (parent => child):
>
>    xterm => zsh => zsh
>
> There is no way for an arbitrary zsh process to affect the environment
> of an arbitrary xterm process.

Yeah, I understand the 'inheritance'. I just thought that 'export' might 
somehow
be ramped up to overcome that.

We certainly can do what I want, it's just a little bit of trouble:

  	universal() { echo "$1" >>! /tmp/universal; . /tmp/universal }

And in .zshrc:

   	preexec () { [ -e /tmp/universal ] && . /tmp/universal }

Now in xterm #6:

	pts/6 HP-y5--5-Debian1 root /aWorking/Zsh $ universal "trash=trash"

	pts/6 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
	trash

Now hop over to xterm #12:

	pts/12 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
         trash

... so we can universally export instantly.  I normally have four xterms
open at the same time, so being able to do that is very handy.

The above is obviously rather crude, but it's simple and it works. And you
can throw a command in there too.

As Kurtis said, it might be dangerous, but I live on the edge ;-)

-----------------------
 >FYI, the "fish" shell does that.

 >set -U universal its value

 >and that $universal variable (here an array) becomes available
 >in all the fish shells (interactive or not) by the same user on
 >the machine (with all the security implications it entails).

That's very cool, I think we should have it too.

Re: export

[Павлов Николай Александрович]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On November 26, 2014 8:43:51 PM EAT, Ray Andrews <rayandrews@eastlink.ca> wrote:
>All:
>
>> Each process gets a private copy of the environment provided by its
>> parent. An xterm is just a process. In your example you have this
>chain
>> of processes (parent => child):
>>
>>    xterm => zsh => zsh
>>
>> There is no way for an arbitrary zsh process to affect the
>environment
>> of an arbitrary xterm process.
>
>Yeah, I understand the 'inheritance'. I just thought that 'export'
>might
>somehow
>be ramped up to overcome that.
>
>We certainly can do what I want, it's just a little bit of trouble:
>
>  	universal() { echo "$1" >>! /tmp/universal; . /tmp/universal }
>
>And in .zshrc:
>
>   	preexec () { [ -e /tmp/universal ] && . /tmp/universal }
>
>Now in xterm #6:
>
>	pts/6 HP-y5--5-Debian1 root /aWorking/Zsh $ universal "trash=trash"
>
>	pts/6 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>	trash
>
>Now hop over to xterm #12:
>
>	pts/12 HP-y5--5-Debian1 root /aWorking/Zsh $ echo $trash
>         trash
>
>... so we can universally export instantly.  I normally have four
>xterms
>open at the same time, so being able to do that is very handy.
>
>The above is obviously rather crude, but it's simple and it works. And
>you
>can throw a command in there too.
>
>As Kurtis said, it might be dangerous, but I live on the edge ;-)
>
>-----------------------
> >FYI, the "fish" shell does that.
>
> >set -U universal its value
>
> >and that $universal variable (here an array) becomes available
> >in all the fish shells (interactive or not) by the same user on
> >the machine (with all the security implications it entails).
>
>That's very cool, I think we should have it too.

This feature is constantly getting me mad. I have set some variable for testing and some code exported it. Now all shells are in the same state, including the new ones. Super! I am getting mad even though I use fish *only* for testing.

I do not think that this feature should be in a zsh core, especially given that it can easily be implemented as a plugin.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJUdhtpMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIpgrD/9pSppBKJ/HB8SacGstcHrv
Y7YAXQ0ty9uQyitrMuQh+Ob56E8x8TpwSEzVSepIeP8GF/u1VKwkIZhRpUrpe+lh
NXB8GevDXzn3kxqu4n3x1GVXnqQ/nBKRxD0owU18j1x4DidFhyA592Mu+SVZQeY+
KFs8gVIxzRMMdgOyJ4suyJMrx2S7JmyXsCkJuu2wKjhpODzXw7oUk95OEnLJnlbK
Q0adJgWN1pR10hnEDJuHGJ/uz3+UTpjZK95r1xm5GmGjcpI80GjOs218oqJIADwJ
Ht/LThPnzZT8KJxu/d2NQ8LWg2nAtEZTiU96vEWMCmZU8duqg/DVVvieETba7F57
SZyM7WkDEcwE+zn5x/5+2hiWtexW27d5/ohB+yOHIUpWHgUD6cDuJvNQug0dDePK
i6wiJ34L7NkUDuopr6mtm2Y9uL0T6Lt+nuWPCrzqYst+cf3W2/PYIUXwibTyOA2G
031+pI+fjKxScyTLVgc3D48iKcjEykA4Yx10VxXIsqlQo2w0Pn9fI5jiWKCPDcWy
XiQjsPdknqhUTQ5ZUGxAwSnkVBKqz5wktdmprof67SVctIQfSbvQmIi8QWFhlKmu
eNIu4y3uSqAxy7nlVsBc214pJ7+TmEodTItPPirDhfR8me0CzDStXHFfJKO5jeq/
Qt5RgCGQl6Xf0dgw+B3uAA==
=KLt8
-----END PGP SIGNATURE-----

Re: export

[Ray Andrews]

>> That's very cool, I think we should have it too.
>
> This feature is constantly getting me mad. I have set some variable
> for testing and some code exported it. Now all shells are in the same
> state, including the new ones. Super! I am getting mad even though I
> use fish *only* for testing.
>
> I do not think that this feature should be in a zsh core, especially
> given that it can easily be implemented as a plugin.

Well, whatever the case, it should be a deliberate action to turn it on.
There's no question of wanting such a feature to be active when you
don't want it.  Anyway, it's easy enough to implement locally so
unlikely it will change officially.  When I started with zsh, I wanted all
my terminals to be basically exactly the same as each other, as if they were
windows into the same shell.  More and more I like having them
different, but some easy way to share things would still be nice.
Sharing history is for me essential, and of course we have that.