look at setenv() for setting or creating an environment variable in a c program. There isn't a need to call a C program simply to set an environmental variable. You can assign a variable and export that variable in a bash script.

Well this is an open question that can be taken at least two ways.


1) Why are you using a "fprintf" rather than an exit code?

Well an exit code can only contain the values of 0-255 for one thing
and since bash allows the assignment of stdout of a command, I choose the most general case which is to return a value in via stdout and hence a print. But please continue to read the next segment if this is the question that you were asking.



2) Why are you using a "fprintf" rather than a "printf"?


I always write C code where the "File Descriptor" (For C++ the "stream") is passed. This is because in Unix/Linux old-timers find code written that use the "File Descriptor/stream" is much more flexible than a function that passes in the file name.

For example you have a compressed file that is currently 2 Gigabytes of space. You know that it is just text. By passing the file descriptor, the file does not need to be de-compressed onto the hard drive and then read. The "popen" function can be used to get the field descriptor of the pipe that is de-compressing and read via the pipe. Remember that a pipe blocks the producer when the consumer is too slow, so it does not fill up the disk space. When a younger developer writes the function with a file name, the compressed file must be decompressed prior to reading it.

So I always used the fXXX i/o functions in my C code. I am not a lazy coder because the re-use of code well written can save much more time than using "printf" rather than "printf".



Does this help you understand why I used printf.

You can use this method to pass data to a child process, but not to a parent process. A copy of an environment variable that is created by a shell will be visible to a C program launched by the shell. Any modification to to the environment variable by the C program will not be seen by the parent shell, because the C program sees only a copy of the one owned by the parent shell.

The possibilities for communicating between a parent and child process are described very well in

Beej's Guide to Unix Interprocess Communication

--- rod.