By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,876 Members | 1,191 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,876 IT Pros & Developers. It's quick & easy.

fork call

P: n/a
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

May 23 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a


an********@gmail.com wrote On 05/23/06 13:28,:
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>

--
Er*********@sun.com

May 23 '06 #2

P: n/a
an********@gmail.com wrote:
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

May 23 '06 #3

P: n/a
>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
May 23 '06 #4

P: n/a
go***********@burditt.org (Gordon Burditt) writes:
I am wondering why a call to fork fails to print some statements in
the child.


fork() by itself does not print anything.


The question was posted by an********@gmail.com. Gordon, as usual,
refuses to provide attributions, so I'll do it for him.

--
Keith Thompson (The_Other_Keith) 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.
May 23 '06 #5

P: n/a
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:
I am wondering why a call to fork fails to print some statements in
the child.


fork() by itself does not print anything.


The question was posted by an********@gmail.com. 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?

May 23 '06 #6

P: n/a

"santosh" <sa*********@gmail.com>.
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:
>>I am wondering why a call to fork fails to print some statements in
>>the child.
>
> fork() by itself does not print anything.


The question was posted by an********@gmail.com. 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?


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
May 23 '06 #7

P: n/a
"santosh" <sa*********@gmail.com> writes:
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:
>>I am wondering why a call to fork fails to print some statements in
>>the child.
>
> fork() by itself does not print anything.
The question was posted by an********@gmail.com. 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?


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?

--
Keith Thompson (The_Other_Keith) 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.
May 23 '06 #8

P: n/a
santosh wrote:
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:
I am wondering why a call to fork fails to print some statements in
the child.
fork() by itself does not print anything.

The question was posted by an********@gmail.com. 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?

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.
May 23 '06 #9

P: n/a
santosh wrote:
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:
I am wondering why a call to fork fails to print some statements in
the child.
fork() by itself does not print anything. The question was posted by an********@gmail.com. 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?


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
sp**@flash-gordon.me.uk.
--
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
May 23 '06 #10

P: n/a
an********@gmail.com 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
OOOOOOOOOO! NAVY SEALS!
May 24 '06 #11

P: n/a
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
[...]
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.

--
Keith Thompson (The_Other_Keith) 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.
May 24 '06 #12

P: n/a

an********@gmail.com wrote:
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

Any clue ?

Anshul


May 24 '06 #13

P: n/a
santosh wrote:
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:

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

fork() by itself does not print anything.


The question was posted by an********@gmail.com. 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?


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/>
May 24 '06 #14

P: n/a
CBFalconer wrote:

santosh wrote:
Keith Thompson wrote:
go***********@burditt.org (Gordon Burditt) writes:

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

fork() by itself does not print anything.

The question was posted by an********@gmail.com. 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?


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?

--
pete
May 24 '06 #15

P: n/a
an********@gmail.com wrote:
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.

--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
May 24 '06 #16

P: n/a

"pete" <pf*****@mindspring.com> wrote
[snip]
>>santosh wrote: >>>> 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
May 24 '06 #17

P: n/a
On 2006-05-24 14:54:17 +0200, pete <pf*****@mindspring.com> said:

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?


Unix-related ones.

--
Sensei <se******@mac.com>

The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true. [J. Robert Oppenheimer]

May 24 '06 #18

P: n/a
In article <44***********************@reader4.news.tin.it>,
Sensei <se******@mac.com> wrote:
On 2006-05-24 14:54:17 +0200, pete <pf*****@mindspring.com> said:
What are the newsgroups where
fork calls are on topic?

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.)
--
Programming is what happens while you're busy making other plans.
May 24 '06 #19

P: n/a
Joe Smith wrote:
"pete" <pf*****@mindspring.com> wrote
>>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/>
May 24 '06 #20

P: n/a
Joe Smith wrote:

"pete" <pf*****@mindspring.com> wrote
[snip]
>>santosh wrote:>>> 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:-)


I used to cut threads on pipes in a machine shop.

--
pete
May 25 '06 #21

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
news:44***********@mindspring.com...
Joe Smith wrote:

"pete" <pf*****@mindspring.com> wrote
[snip]
>> >>santosh wrote:

>> >>>> 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:-)


I used to cut threads on pipes in a machine shop.


Hence, your attention to detail. I'm going bats trying to figure out how
the pipefitter did whatever he did above me. I wonder if I can describe it
abstractly. The node I observe first has order 4, the second order 3, the
third order three, the fourth order two, the fifth order two; the sixth may
either have order two or simply be called NULL . Every day, as I look, not
at a blueprint, but the actual installation, I call it impossible. Then I
tell myself I just Don't Get It (tm). joe
May 25 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.