Re: Spawning process with environment variables

drew@xxxxxxxxxxxxxx (Drew Lawson) writes:
Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
jt@xxxxxxxxxxx (Jens Thoms Toerring) writes:

If you don't mind a shell running the command for you simply use
the system(3) function - it's return value is the exit valur of
the command that has been run (assuming there was no error when
starting the shell).

That assumes that one also "does not mind" generating a shell script
which performs the environment variable assignments and calls the
command on the fly. In C, I presume. I know that every grotty
derelict which fell into the C library because somebody had a bad hung
over in 1978 Is To Be Used Because!, but that's really ridicolous.

Sorry, I am not sure what you mean here - it looks a bit as if you
don't like the system() function but at least to me it doesn't be-
come clear why.

To me, it appears that he doesn't know the difference between "a
shell running the command" and writing and then executing a new
shell script.

There is no difference at this level: Every system invocation passes
a single-line script to a shell for execution. This script could
altenatively have been written to a file (especially, when the intent
is to execute another command with an invariant set of custom
environment variables) and this file could be passed to the shell
instead. But for the simple case, what is the reason for
invoking a library call which creates a coprocess whose purpose is to
create another coprocess? And why to do write C-code to control
execution of shell scripts instead of writing shell script controlling
the execution of (smaller) program written in C? This procedure alone
will eat any hypothetical time savings in developer time three times
over.


.