linux redirect problem

[cmk128]

Hi
here is my c file, compile in gcc 3.X in linux:

#include <stdio.h>

int main()
{
printf("Hello\n");
if (fork() == 0) printf("world! \n");
}


When i execute the a.out like this:
a.out > myFile.

Inside myFile:
Hello
Hello
world!

How come?
thanks
from Peter ([email protected])

 

[Bill Pursell]

Hi
here is my c file, compile in gcc 3.X in linux:

#include <stdio.h>

int main()
{
printf("Hello\n");
if (fork() == 0) printf("world! \n");
}


When i execute the a.out like this:
a.out > myFile.

Inside myFile:
Hello
Hello
world!

How come?
thanks

1) The root of the question is off-topic, but I'll answer.
You need to flush the output stream before the fork. The
first printf is putting "Hello\n" into the buffer. The child
inherits that buffer before it is flushed, so when it prints
"World", it is also printing the "Hello" that the parent had
put in the buffer.

2) Your program is invoking undefined behavior because
of an incorrect prototype for main. Also, you failed to
include a prototype for fork(). (it's in <unistd.h>)

 

[Keith Thompson]

#include <stdio.h>

int main()
{
printf("Hello\n");
if (fork() == 0) printf("world! \n");
}

fork() is not part of standard C. Try comp.unix.programmer.

 

[Flash Gordon]

2) Your program is invoking undefined behavior because
of an incorrect prototype for main.

No, it's a valid definition for main. Obsolescent possibly, but valid.

> Also, you failed to
include a prototype for fork(). (it's in <unistd.h>)

If fork takes no parameters and returns an int that does not lead to
undefined behaviour. However, I agree that the correct header should be
included.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Lew Pitcher]

1) The root of the question is off-topic, but I'll answer.
You need to flush the output stream before the fork. The
first printf is putting "Hello\n" into the buffer. The child
inherits that buffer before it is flushed, so when it prints
"World", it is also printing the "Hello" that the parent had
put in the buffer.

It is worth noting that there will be a difference in the behaviour of
the OPs posted code, depending on whether or not he redirects stdout to
a file.

<note>
The following will be semi-off-topic. While it primarily deals with
behaviours invoked from non-C-standard functions (fork()), it also
deals with the side-effects of behaviours specified by the C standard.
As I cannot find a corresponding thread in any Linux or Unix newsgroup,
I thought it worthwile to respond here. My apologies to newsgroup
topicality pedants.
</note>

In the case of a redirect, stdout is buffered, and not automatically
flushed with the '\n' character (C standard behaviour). This means
that, in the case of the OPs code,
a) the parent process will not flush it's output until the termination
of the main() function, which implies that the buffer is not yet
flushed when fork() is invoked, and
b) the child process will not flush it's output until the termination
of the main() function.

So, in the case of a redirect to file, the output will consist of
a) a line reading "Hello", generated by the parent process and written
on termination of the parent process,
b) a line reading "Hello", inherited from the parent process by the
child process, and written on termination of the child process, and
c) a line reading "World", generated by the child process and written
on termination of the child process

OTOH, in the case of no redirect, stdout is buffered, and flushed
automatically with each '\n' (again, by the C standard). Thus, the
child process will /not/ inherit an unflushed buffer, and will not
print the redundant "Hello". For this pattern, the output will consist
of
a) a line reading "Hello", generated by the parent process and written
on termination of the parent process, and
b) a line reading "World", generated by the child process and written
on termination of the child process

 

[Bill Pursell]

No, it's a valid definition for main. Obsolescent possibly, but valid.

Bill Pursell said:

For each argv[n] where n >= 0 && n < argc, you can write to the
characters starting with argv[n][0] and going no further than the null
terminator.

Which is clear if you prototype main as int main(int argc, char
*const*argv),
plus you'll get a compiler warning if you try to write the values.

That's fine, provided your implementation documents that form for main().
Otherwise, ISTM that you are invoking undefined behaviour.

Is that consistent with what your saying? Is
int main()
merely obsolescent, or does it invoke undefined
behavior. If the former, is that consistent with Richard's
comment? I'm a little confused on this point.

 

[Richard Heathfield]

Bill Pursell said:

Flash Gordon wrote:

[ int main() ]

No, it's a valid definition for main. Obsolescent possibly, but valid.

Bill Pursell said:

Richard Heathfield wrote:
For each argv[n] where n >= 0 && n < argc, you can write to the
characters starting with argv[n][0] and going no further than the null
terminator.
Which is clear if you prototype main as int main(int argc, char
*const*argv),
plus you'll get a compiler warning if you try to write the values.

That's fine, provided your implementation documents that form for main().
Otherwise, ISTM that you are invoking undefined behaviour.

Is that consistent with what your saying?
Yes.

Is int main() merely obsolescent,
Yes.

or does it invoke undefined behavior.

No. In the function definition, an empty parameter list is exactly
equivalent to a parameter list of void, so it's equivalent to
int main(void) which is one of the standard forms.

For future-proofing and good style, favour int main(void), but int main() is
not actually wrong.