Re: initialisation bash variables

[Stephane CHAZELAS]

2011-08-18, 04:10(+02), Patrick:
> On 17.08.2011 20:53, Stephane CHAZELAS wrote:
>> 2011-08-17, 08:32(+02), Francky Leyn:
>>> On 8/16/2011 10:53 PM, Stephane CHAZELAS wrote:
>>> 2) If VAR coincides with an environment variable, and in the
>>>      script I change it value, is this then propagated to outside
>>>      the script? Is the environment variable affected?
>>
>> The environment is a list of strings (by convention of the format
>> [...]
>>
>> In no circumstance are variable definitions in one process going
>> to affect the environment of other processes (an exception to
>> that is the "fish" shell)
>>
>
> Could it be that the two of you are not talking about the same thing?
>
> Just for clarity: environment variables (henceforth "the environment") 
> of a process are (is) inherited by its children.

Everything is inherited by children, however upon executing a
command using the execve(2) system call, all the memory is
of a process is reinitialised. What the new command gets passed
along the execve(2) system call (as arguments) is a list of
arguments (argv) and a list of environment variables (envp).

And as I said, by convention (and helped in that way by C
library function wrappers around the execve(2) system call
(execv, execl, system...) that take care of propagating the
environment) that envp is built by the application from the envp
it received when it was executed (in that process or its
parents).

So yes, generally, environment generally is inherited by
commands executed in children processes but also by the current
process.


> Therefore, what *does* happen, is that if Stephane, as in 2), changes 
> VAR in script, the change gets propagated to the scripts *child* processes.

I think it brings confusion to speak of processes here.
Everything is propagated upon a fork() (the system call that
creates a child process), a fork creates an exact same copy of
the current process. The environment is something that concerns
command execution.

As a side note though, that behavior didn't occur in the Bourne
shell. In the bourne shell, you had to explicitely export a
variable (even if the shell received itself in its environment),
for it to be exported to the commands executed by the shell.

$ VAR=foo sh -c 'VAR=bar; env' | grep VAR
VAR=foo
$ VAR=foo sh -c 'VAR=bar; export VAR; env' | grep VAR
VAR=bar

[...]
> But what does of course not happen, is that the change would get 
> propagated to the *parent* process.

Or any other process.

environment changes are propagated to children just like the
rest of the memory and generally to commands executed by the
current process or any of those children

> (What is the "fish" shell ???)

The friendly interactive shell.

http://en.wikipedia.org/wiki/Friendly_interactive_shell

And see http://fishshell.com/user_doc/index.html#variables for
the documentation on the scope of its variables.

-- 
Stephane