[Lazarus] SetEnv on Linux 64bit

[Honza]

2012/4/4  <michael.vancanneyt at wisa.be>:

Thank you for the help. Unfortunately I'm now confused even more. I
believe it's my fault, not yours.

> You can always modify them (it's just data in memory), but modifying them
> will only change your private view of the variables. The changes you make
> will not propagate to libraries or newly started processes.

If "library" means a .so (or .dll, but Windows are not that much of a
Posix system), then it is in in-process space, so I would think the
change *does* propagate, i.e. the change is observable by a call to
getenv() from inside a library function. About started processes see
below.

>
> Therefor it makes no sense to change them, and the FPC runtime does not
> allow
> it. If we did allow it, people would expect DOS/Windows like behaviour,
> which
> we simply cannot provide.
>
> If you read the second part of the provided URL, you'll see that the POSIX
> group recognises that the behaviour of setenv() is problematical.
>
> The URL points - for restrictions - to the exec function
>
> http://pubs.opengroup.org/onlinepubs/007904975/functions/exec.html
>
> Where it says:
>
> "For those forms not containing an envp pointer ( execl(), execv(),
> execlp(),
> and execvp()), the environment for the new process image shall be taken from
> the external variable environ in the calling process."

The extrn char **environ (just environ from now on) points to the
environment variables of the executing process. Setenv may mutates
this environment. The various forms of exec do have either explicit
envp, so one can create any required environment vars set, or pass the
current environ, effectively enabling the inheritance of the (posibly
mutated) environment as an option.

The other forms, w/o envp, are defined to do exactly that, i.e. they
will use the current environ as their environment vars pointer,
effectively forcing the inheritance of the (possibly mutated)
environment. ("the environment for the new process image shall be
taken from the external variable environ in the calling process")

I honestly presume I'm extra dumb today, anyway it still seems to me
like the opposite of what was said in this thread is true:

Environment variables can be mutated, the changes are visible in a
library (.so or and maybe in a .dll too) and with exec() one can
choose if to pass a new environment or if the current one is to be
inherited.

Apologies, I don't want to sound like a troll, I just want to figure
out why the same Posix specs can be seen/interpreted in two mutually
exclusive ways and naturally - which one is the correct
interpretation.

PS: I've just cross-checked with some other language (Go if you are
curious) and its std library and there seems to work all like I think
the Posix specs says (http://golang.org/pkg/os/#Setenv and
http://golang.org/pkg/os/exec/#Cmd) and I think the high level (and
cross platform, Go programs should behave identically on Linux and
Windows) wrapper of the Go 'os' package just reiterates the standard
Posix behavior in a libc independent way.

-- jan