fork call

[anshul1806]

hi all ,

I am wondering why a call to fork fails to print some statements in
the child.

It works fine when terminal is defualt for O/p .

in case i try redirection it fails to redirect all the print
statements .

Any clue ?

Anshul

 

[Eric Sosman]

hi all ,

I am wondering why a call to fork fails to print some statements in
the child.

It works fine when terminal is defualt for O/p .

in case i try redirection it fails to redirect all the print
statements .

Try a "redirection" to an appropriate newsgroup,
possibly comp.unix.programmer. Follow-ups set.

<off-topic>

And when you go there, for goodness' sake learn to
write an accurate problem report! For the record, fork()
doesn't print anything, isn't expected to print anything,
and doesn't do anything about I/O redirection. You are
therefore writing about the things that *don't* pertain
to your problem, which isn't the best way to get help in
reaching a solution.

</off-topic>

 

[Robert Gamble]

hi all ,

I am wondering why a call to fork fails to print some statements in
the child.

It works fine when terminal is defualt for O/p .

in case i try redirection it fails to redirect all the print
statements .

Any clue ?

Wrong group, try comp.unix.programmer.

Robert Gamble

 

[Gordon Burditt]

I am wondering why a call to fork fails to print some statements in

the child.

fork() by itself does not print anything.

How did you redirect output? You should call fflush(NULL) or
fflush() your output streams before fork() to avoid dupliate
output held in buffers. Note that output to a file may be
buffered, so you may need to call fflush() to see output
if the program is waiting for something.

It works fine when terminal is defualt for O/p .
Octal/pointers?

in case i try redirection it fails to redirect all the print
statements .

Did you redirect stdout *and* stderr?

Any clue ?

The problem is in line 42 of the code you didn't include.

Gordon L. Burditt

 

[Keith Thompson]

fork() by itself does not print anything.

The question was posted by (e-mail address removed). Gordon, as usual,
refuses to provide attributions, so I'll do it for him.

 

[santosh]

The question was posted by (e-mail address removed). Gordon, as usual,
refuses to provide attributions, so I'll do it for him.

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be able to
read the posts up-thread and deduce the attributions?

Do you really plan on supplying attributions to each and every one of
Gordon's posts to this group, let alone whatever he might post
elsewhere on Usenet?

 

[Joe Smith]

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be able to
read the posts up-thread and deduce the attributions?

Do you really plan on supplying attributions to each and every one of
Gordon's posts to this group, let alone whatever he might post
elsewhere on Usenet?

Superlative for primitive is 'most primitive'. The regulars, meaning guys
like Keith Thompson who consistently provide quality posts and probably plow
through a hundred a day, are finding frustration with many of the posts from
a standpoint of readability, contnuity and attribution. joe

 

[Keith Thompson]

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be able to
read the posts up-thread and deduce the attributions?

I can jump to the parent article -- *if* it happens to be on my
server. (That's how I figured out who posted the question.) To do
so, I have to interrupt my reading of the current article, and getting
back to the followup article can be non-trivial.

I see that you include attribution lines in your posts. If it's so
easy to deduce attributions, why do you bother?

The point is that I shouldn't have to do this just to find out who
posted the previous article. That's what attribution lines are for.
Gordon deliberately deletes attribution lines, for reasons that are
based on some astonishing claims he's made. This was recently
discussed here at length, but Gordon dropped out of the discussion had
has not, in my opinion, given adequate justification for his behavior.

Do you really plan on supplying attributions to each and every one of
Gordon's posts to this group, let alone whatever he might post
elsewhere on Usenet?

I'm making a point about Gordon's deliberate failure to follow Usenet
norms. I haven't decided how or whether I'll do so in the future. Do
you plain on complaining every time I raise this point?

 

[Clever Monkey]

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be able to
read the posts up-thread and deduce the attributions?

Do you really plan on supplying attributions to each and every one of
Gordon's posts to this group, let alone whatever he might post
elsewhere on Usenet?

My USENET provider (or its peers) expires messages pretty aggressively.
Some upthread messages disappear in a matter of /hours/. In order to
make sense of a posting I've often had to look on Google Groups. As
long as the poster has not set extended headers to expire archives this
may work, but it's a hell of a lot more work than simply having people
properly quote some relevant context.

So, I don't think this gentle reminder is not unwarranted. Whether such
reminders will be terribly successful after several years of a
never-ending autumn due to AOL (and Prodigy, CompuServ, Delphi, ...),
WebTV and Google Groups remains to be seen.

 

[Julian V. Noble]

hi all ,

I am wondering why a call to fork fails to print some statements in
the child.

It works fine when terminal is defualt for O/p .

in case i try redirection it fails to redirect all the print
statements .

Any clue ?

Anshul

fork is a system subroutine, not part of C per se, although doubtless
defined by a C program.

 

[Flash Gordon]

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be able to
read the posts up-thread and deduce the attributions?

So whenever I read one of Gordon's posts I am supposed to change from my
default view which only shows unread messages, something I don't have to
do for others posts? Also, what if the post hasn't arrived yet?

Do you really plan on supplying attributions to each and every one of
Gordon's posts to this group, let alone whatever he might post
elsewhere on Usenet?

I doubt it. Keith is making a point, one which I and a number of others
agree with. Namely that Gordon should be providing the attributions.

Parts of this post are copyright Mark Gordon and may not be reproduced
without attribution to either Mark Gordon , Flash Gordon, or
(e-mail address removed).

 

[SM Ryan]

(e-mail address removed) wrote:
# hi all ,
#
# I am wondering why a call to fork fails to print some statements in
# the child.

fork() doesn't know about stdio, and stdio doesn't know when it's
been forked (up). You have to handle buffer synchronizations in
the parent and child by hand, or not use stdio.

 

[Keith Thompson]

fork() doesn't know about stdio, and stdio doesn't know when it's
been forked (up).

And standard C doesn't know about fork().

Try comp.unix.programmer.

 

[sandy]

hi all ,

I am wondering why a call to fork fails to print some statements in
the child.

It works fine when terminal is defualt for O/p .

in case i try redirection it fails to redirect all the print
statements .

There is some problem with the buffering and fork ( ). Read the
Advanced programming in the UNIX environment chapter 3. They have
discussed the problem with the solution to it...


Cheers,
Sandeepksinha

 

[CBFalconer]

Err, don't you think everyone except those using the primitivest of
newsreaders and very poorly retentive Usenet providers would be
able to read the posts up-thread and deduce the attributions?

Nope. For example, I periodically clear out all the previously
downloaded information in a newsgroup. After that there are no
up-thread posts to read. And you are also assuming that any such
up-thread post did actually arrive, which is not guaranteed.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[pete]

Nope. For example, I periodically clear out all the previously
downloaded information in a newsgroup. After that there are no
up-thread posts to read. And you are also assuming that any such
up-thread post did actually arrive, which is not guaranteed.

What are the newsgroups where
fork calls are on topic?

 

[Joe Smith]

What are the newsgroups where
fork calls are on topic?

Forks, pipes, segments. These are, for me, three very similar things. The
fork is on the left hand side of the plate. The pipes run overhead. BTW, I
liked the link you posted for pipes recently And segments populate the
bag of tricks of a geometer. Clearly the terms have relevance to C on Unix.
When I hear about them in clc, before they get shooed off, the forks fail,
the pipes fail, and of course "segmentation fault" is turning into a stock
epithet. If I were talking to a person who advocated that these things be
accomodated within Standard C, I would tell them that they seem to be
trouble enough for the Unix users. Are there better reasons? joe

 

[Sensei]

What are the newsgroups where
fork calls are on topic?

Unix-related ones.

 

[Walter Roberson]

On 2006-05-24 14:54:17 +0200, pete <[email protected]> said:

Unix-related ones.

And POSIX.1 related ones. You'd probably even get somewhere
with Linux newsgroups, even though Linux is neither Unix nor POSIX.1
(or at least not certified as such.)

 

[CBFalconer]

santosh wrote:

[snip]

I am wondering why a call to fork fails to print some
statements in the child.

What are the newsgroups where fork calls are on topic?

Forks, pipes, segments. These are, for me, three very similar
things. The fork is on the left hand side of the plate. The
pipes run overhead. BTW, I liked the link you posted for pipes
recently And segments populate the bag of tricks of a geometer.
Clearly the terms have relevance to C on Unix. When I hear about
them in clc, before they get shooed off, the forks fail, the pipes
fail, and of course "segmentation fault" is turning into a stock
epithet. If I were talking to a person who advocated that these
things be accomodated within Standard C, I would tell them that
they seem to be trouble enough for the Unix users. Are there
better reasons? joe

My user accessible pipes are all black, and rise straight up. Not
an elbow in the whole run. In operation they run quite hot.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>