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 (cm****@hotmail .com)

[Bill Pursell]

cm****@hotmail. com wrote:

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]

cm****@hotmail. com writes:

#include <stdio.h>

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

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

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

Bill Pursell wrote:

cm****@hotmail. com wrote:

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");
}

<snip>
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]

Bill Pursell wrote:

cm****@hotmail. com wrote:

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.

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
--
Lew Pitcher
(temporarily without GPG keys)

[Bill Pursell]

Flash Gordon wrote:

Bill Pursell wrote:

cm****@hotmail. com wrote:

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");
}
<snip>

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.

A few days ago, in a different thread, Richard Heathfield wrote: 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? 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.

A few days ago, in a different thread, Richard Heathfield wrote:

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)