2012/4/4 <[email protected]>: 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
