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

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