It is currently Mon, 27 Jun 2022 11:29:22 GMT



 
Author Message
 problem with exporting a shell variable from a C Program

You might save yourself some time, unless Unix has changed in recent years.
The environment is exported *only* to child processes. You can not spawn
a child, have it export variables and expect to see them in the parent.
It doesn't work. (I know; I stumbled over this a number of times until
it sank in!)

For a child to pass information back to a parent, it needs to put the info
either in a file, in a pipe, or in shared memory. Then, if it's in a file,
the parent will read the file after it detect the child's death. If the data
arrives in a pipe, the parent can read the pipe until EOF and grab the data
that way.

To reiterate, a child cannot put data into its environment and expect the
parent to access it. Environment is not shared; it is copied from parent
to child.

Fest3er
--
For your information I had Mrs Levrat on the phone this morning (for a
dumb{*filter*}problem).

  - Frederic Kayser



 Sun, 13 Feb 2000 03:00:00 GMT   
 problem with exporting a shell variable from a C Program

In article <murphyn.872724219@orca>, murp...@orca.cig.mot.com (Neal P. Murphy) writes:
|> r...@news.austx.tandem.com (Rory Foster) writes:
|>
|> >In article <5u1kfs$...@jungle.escortnet.com>, "TAKASBANK" <ta...@escortnet.com.tr> writes:
|> >|> ...but the shell script that I call from the C program does not export these
|> >|> tty's to the environment...
|> >|>
|>
|> >Look at "man execv".  You need more functionality than
|> >system() provides.  Consider doing the fork() and execv()
|> >yourself rather than requesting system() to do the work.
|>
|> You might save yourself some time, unless Unix has changed in recent years.
|> The environment is exported *only* to child processes. You can not spawn
|> a child, have it export variables and expect to see them in the parent.
|> It doesn't work. (I know; I stumbled over this a number of times until
|> it sank in!)
|>
|> For a child to pass information back to a parent, it needs to put the info
|> either in a file, in a pipe, or in shared memory. Then, if it's in a file,
|> the parent will read the file after it detect the child's death. If the data
|> arrives in a pipe, the parent can read the pipe until EOF and grab the data
|> that way.
|>

Hmm, looks likes I parsed the question incorrectly.  Indeed, it would be
impractical for the child to modify the parent's environment.  It would
be better to select a means of interprocess communication.  One that was
not mentioned is message queues.  (There may be some way of using semaphores,
but in the given example it seems like a poor choice.)

Notice, I said "impractical" rather than "can not", because I remain
unconvinced that it is impossible.  I can imagine a child process
that locates it's parent's proc structure in /dev/kmem.  From there
it locates the seg structure for the stack segment of the parent.  It
would then read s_base and manuiplate the stack in order to modify
the environment of the parent.  If you are certain it cannot be done,
please convince me that it is impossible.

Finally, please note that I do not recommend this as a means of
solving the problem stated in the original post.  In fact, I think
an mmap file would do just fine.  Or recoding the shell script as
C language source code and linking to the original C program.

--
Rory Foster



 Mon, 14 Feb 2000 03:00:00 GMT   
 
   [ 2 post ] 

Similar Threads

1. export variables to calling shell in a shell-script

2. export variables to calling shell in a shell-script

3. How do i transfer the contents of shell variable to a variable used in C program

4. Problem in Reading Program Output to a Shell Variable

5. Exporting Enviroment Variables in shell scripts

6. make - exporting shell variable to environment

7. exporting C shell variable

8. how do I export a shell variable

9. Adding/Changing an exported Shell Variable

10. csh shell, problem with echoing variable variables...


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software