putenv() & shell variable scope
Ok, not seeing any reply, I try to pose the question in a more general mode:
From within a C++ program I need to set a shell global variable in a permanent mode, such that the variable with its content will be available after the program terminates.
Any idea how to achieve that?
===================================
From within a C++ program I need to set a shell (bash) variable in a permanent mode, such that when the program will be launched again later, it will find that variable with the value previously set.
I'm confused about the scope of a variable set with putenv():
Doing simply this...
...I notice that once the program terminates, $MYVAR is empty: the command >echo $MYVAR prints nothing.
So, what is the scope of MYVAR?
Unfortunately, this does not work because of the blank space in the string:
I'd appreciate some direction. Thanks.
From within a C++ program I need to set a shell global variable in a permanent mode, such that the variable with its content will be available after the program terminates.
Any idea how to achieve that?
===================================
From within a C++ program I need to set a shell (bash) variable in a permanent mode, such that when the program will be launched again later, it will find that variable with the value previously set.
I'm confused about the scope of a variable set with putenv():
Doing simply this...
|
|
...I notice that once the program terminates, $MYVAR is empty: the command >echo $MYVAR prints nothing.
So, what is the scope of MYVAR?
Unfortunately, this does not work because of the blank space in the string:
|
|
I'd appreciate some direction. Thanks.
Last edited on
Short answer - you can't do this!
When a new process, such as your C++ program is started it receives a COPY of the environment from its parent process. Any changes the program makes to the environment will be copied to any child processes it may create and may also affect the way that certain parts of the runtime library behave in the current program (e.g., setting the TZ variable before calling tszet() will modify the way that some time functions behave)
Your first example works because system() creates a child process to run the shell, which inherits a copy of your program's environment. Once the program has finished, the modified environment is destroyed along with the rest of the memory used by the program.
You second example doesn't work because it is trying (and possibly succeeding, depending on the implementation!) to create a variable called "export MYVAR". export is a shell built-in command that modifies properties of environment variables created by the shell such that they will get inherited by child processes.
There is no (supported/portable) way for a process to get access to the environment of its parent process and therefore no way for a program to set environment variables that will persist after it has exited.
[I have in fact done what you are attempting under the old DOS system in the early 1980s. This worked because the shell process remained in memory while the child was running and it was possible to find the memory address of the parent process and thus the environment. However, this was fraught with problems since there was no way of finding out how much memory was allocated for the parent environment and thus no way of knowing if there was space for the new variable or updated value. So updating the parent environment may work fine or it could result in everything crashing, either immediately or some time later on!]
Graham
When a new process, such as your C++ program is started it receives a COPY of the environment from its parent process. Any changes the program makes to the environment will be copied to any child processes it may create and may also affect the way that certain parts of the runtime library behave in the current program (e.g., setting the TZ variable before calling tszet() will modify the way that some time functions behave)
Your first example works because system() creates a child process to run the shell, which inherits a copy of your program's environment. Once the program has finished, the modified environment is destroyed along with the rest of the memory used by the program.
You second example doesn't work because it is trying (and possibly succeeding, depending on the implementation!) to create a variable called "export MYVAR". export is a shell built-in command that modifies properties of environment variables created by the shell such that they will get inherited by child processes.
There is no (supported/portable) way for a process to get access to the environment of its parent process and therefore no way for a program to set environment variables that will persist after it has exited.
[I have in fact done what you are attempting under the old DOS system in the early 1980s. This worked because the shell process remained in memory while the child was running and it was possible to find the memory address of the parent process and thus the environment. However, this was fraught with problems since there was no way of finding out how much memory was allocated for the parent environment and thus no way of knowing if there was space for the new variable or updated value. So updating the parent environment may work fine or it could result in everything crashing, either immediately or some time later on!]
Graham
Topic archived. No new replies allowed.