Read the man page for system(). It does not return a string, it returns the status of the command, as an integer -- probably 0 most of the time, or nonzero on error. If you want to actually capture the output of the command, use popen, it opens a FILE stream you can read from.
Better yet, don't create external processes for things you can do inside C. See man gettimeofday and man ctime.
That explained why I did not see the return values.
But the command output is still printed.
-> main()
main() passing_var = datum
-> date()
date() passing_var = datum
date() command = date
Tue May 4 15:10:34 GMT 2010
date() date_return = 0
<- date()
main() return_value = 0
<- main()
Probably the command function is not what I need.
I just read that the command function just executes the command and only delivers the exit value of the command executed.
Perhaps I can make use of this.
I do not need the date output, that was just as an example.
I only need an integer, so I will try to use the exit value for this.
---------- Post updated at 05:42 PM ---------- Previous update was at 05:19 PM ----------
As I have control over the exit value of the command executed, I can have the output go to "> /dev/null 2&>1".
Then with "WEXITSTATUS" I can parse the exit value to my variable.
Yes, it prints to standard output and standard error. When you create a new process it gets copies of your file descriptors.
Sure you can. But if that output's the thing you wanted to get, then you're not accomplishing much. By using system() you're executing a whole new shell and running things inside it. Handy sometimes but if you want to program C, not the way things are generally done.
The problem is that I personally do not want to program C.
I need to adjust a program that is written in C by a colleague that left the company.
With minimum effort, if possible.
The program that is being executed actually only needs to return 0, 1 or -1, so that is quite simple.
If I could program C, I would not use a system command at all.
It is basically a C program calling a Perl program, which seems stupid.
Anyway, it is working now and serves its purpose.
Perhaps later I will have a go at it and integrate the Perl program into the C program.
Vice versa sounds a better idea if you want to avoid C entirely. C has a lot of "gotchas" that may surprise you if you're not familiar with the language.