Very Computer

I'l like a clean way for a child process to change or add enviromental
variables to the calling process or parent shell....

Background: I've got a number of legacy systems/applications  which call a
third party's C-routine. The C-routine somehow sets a few environmental
varibles for the parent. The parent continues.

I'm trying to develop a set of utilities which behave the same way, and I'd
like to replace the third party routine with a generic shell or routine. I
need to keep the same calls and return values using the same method so I
won't have to edit the many calling scripts which previously called the
third party routine.

No I don't want to just dump or source a temporary file becuase I'd like to
keep the calls to the third party shell in the calling script without
alterating the calling script

Also, I'm not too nuts about exec'ing a new shell from the child because of
side-effects and parent loosing control of the children.

Any ideas?

Quote:>I'l like a clean way for a child process to change or add enviromental
>variables to the calling process or parent shell....

They can't do it directly.  You could have the child process print the
commands, and the parent could do:

eval `command`

See the tset(1) command for an example of this style.

Quote:>Background: I've got a number of legacy systems/applications  which call a
>third party's C-routine. The C-routine somehow sets a few environmental
>varibles for the parent. The parent continues.

Either I'm misunderstanding you, or this isn't really what's happening.
One process simply cannot set environment variables in another process,
unless it has privileges to write directly into its memory, and even then
it's difficult.  By "C-routine" do you mean "C shell script" or "binary
program created by compiling a C program"?

Quote:>No I don't want to just dump or source a temporary file becuase I'd like to
>keep the calls to the third party shell in the calling script without
>alterating the calling script

Too bad, that's not how Unix works.

This whole issue is discussed in the comp.unix.questions FAQ.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.

Quote:

>Either I'm misunderstanding you, or this isn't really what's happening.
>One process simply cannot set environment variables in another process,
>unless it has privileges to write directly into its memory, and even then
>it's difficult.  By "C-routine" do you mean "C shell script" or "binary
>program created by compiling a C program"?

Yup, Third party routine is a C-program writing to a structure in memory. I
didn't think I could emulate this in shell, unless someone had a trick up
their sleeve I didn't know. Perhaps to set a value in shared memory for the
parent to retrieve or some other technique.

Quote:>Yup, Third party routine is a C-program writing to a structure in memory. I
>didn't think I could emulate this in shell, unless someone had a trick up
>their sleeve I didn't know. Perhaps to set a value in shared memory for the
>parent to retrieve or some other technique.

Why not use a file?

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.

Well, I was trying to avoid changing the legacy apps while retaining
backward compatibility in any new shell applications. I think I found a good
solution.

I created an equivlent shell function, (say "set X") that performs same task
as the previous C-program. Because "set X" is a function and not a shell,
the parent won't fork a new process. The variables set by this new function
continue to exist at the function's termination. If the function exists, the
function is called, else the C-program remains to be called by legacy
applications. Any new app can simply source in the function declaration. The
environmental variable will be set and remain only if the function is called
or if the legacy C-program is called. Later, I can dump the third party
C-program.

Thanks for your input

<snip>