fork call

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

re: fork call

anshul1806@gmail.com wrote On 05/23/06 13:28,:[color=blue]
> 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 .[/color]

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>

--
Eric.Sosman@sun.com

re: fork call

anshul1806@gmail.com wrote:[color=blue]
> 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 ?[/color]

Wrong group, try comp.unix.programmer.

Robert Gamble

re: fork call

>I am wondering why a call to fork fails to print some statements in[color=blue]
>the child.[/color]

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.
[color=blue]
>It works fine when terminal is defualt for O/p .[/color]

Octal/pointers?
[color=blue]
>in case i try redirection it fails to redirect all the print
>statements .[/color]

Did you redirect stdout *and* stderr?
[color=blue]
>Any clue ?[/color]

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

Gordon L. Burditt

re: fork call

gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[color=blue][color=green]
>>I am wondering why a call to fork fails to print some statements in
>>the child.[/color]
>
> fork() by itself does not print anything.[/color]

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

--
Keith Thompson (The_Other_Keith) kst-u@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.

re: fork call

Keith Thompson wrote:[color=blue]
> gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[color=green][color=darkred]
> >>I am wondering why a call to fork fails to print some statements in
> >>the child.[/color]
> >
> > fork() by itself does not print anything.[/color]
>
> The question was posted by anshul1806@gmail.com. Gordon, as usual,
> refuses to provide attributions, so I'll do it for him.[/color]

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?

re: fork call

"santosh" <santosh.k83@gmail.com>.[color=blue]
> Keith Thompson wrote:[color=green]
>> gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[/color][/color]
[color=blue][color=green][color=darkred]
>> >>I am wondering why a call to fork fails to print some statements in
>> >>the child.
>> >
>> > fork() by itself does not print anything.[/color]
>>
>> The question was posted by anshul1806@gmail.com. Gordon, as usual,
>> refuses to provide attributions, so I'll do it for him.[/color]
>
> 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?[/color]

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

re: fork call

"santosh" <santosh.k83@gmail.com> writes:[color=blue]
> Keith Thompson wrote:[color=green]
>> gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[color=darkred]
>> >>I am wondering why a call to fork fails to print some statements in
>> >>the child.
>> >
>> > fork() by itself does not print anything.[/color]
>>
>> The question was posted by anshul1806@gmail.com. Gordon, as usual,
>> refuses to provide attributions, so I'll do it for him.[/color]
>
> 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?[/color]

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.
[color=blue]
> 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?[/color]

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) kst-u@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.

re: fork call

santosh wrote:[color=blue]
> Keith Thompson wrote:[color=green]
>> gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[color=darkred]
>>>> I am wondering why a call to fork fails to print some statements in
>>>> the child.
>>> fork() by itself does not print anything.[/color]
>> The question was posted by anshul1806@gmail.com. Gordon, as usual,
>> refuses to provide attributions, so I'll do it for him.[/color]
>
> 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?
>[/color]
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.

re: fork call

santosh wrote:[color=blue]
> Keith Thompson wrote:[color=green]
>> gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[color=darkred]
>>>> I am wondering why a call to fork fails to print some statements in
>>>> the child.
>>> fork() by itself does not print anything.[/color]
>> The question was posted by anshul1806@gmail.com. Gordon, as usual,
>> refuses to provide attributions, so I'll do it for him.[/color]
>
> 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?[/color]

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?
[color=blue]
> 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?[/color]

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
spam@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

re: fork call

anshul1806@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!

re: fork call

SM Ryan <wyrmwif@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
[...][color=blue]
> fork() doesn't know about stdio, and stdio doesn't know when it's
> been forked (up).[/color]

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

Try comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) kst-u@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.

re: fork call

anshul1806@gmail.com wrote:
[color=blue]
> 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 .[/color]

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



[color=blue]
> Any clue ?
>
> Anshul[/color]

re: fork call

santosh wrote:[color=blue]
> Keith Thompson wrote:[color=green]
> > gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[/color]
>[color=green][color=darkred]
>>>> I am wondering why a call to fork fails to print some statements
>>>> in the child.
>>>
>>> fork() by itself does not print anything.[/color]
>>
>> The question was posted by anshul1806@gmail.com. Gordon, as usual,
>> refuses to provide attributions, so I'll do it for him.[/color]
>
> 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?[/color]

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/>

re: fork call

CBFalconer wrote:[color=blue]
>
> santosh wrote:[color=green]
> > Keith Thompson wrote:[color=darkred]
> > > gordonb.hbxrl@burditt.org (Gordon Burditt) writes:[/color]
> >[color=darkred]
> >>>> 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 anshul1806@gmail.com. Gordon, as usual,
> >> refuses to provide attributions, so I'll do it for him.[/color]
> >
> > 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?[/color]
>
> 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.[/color]

What are the newsgroups where
fork calls are on topic?

--
pete

re: fork call

anshul1806@gmail.com wrote:[color=blue]
> 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
>[/color]

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

re: fork call

"pete" <pfiland@mindspring.com> wrote
[snip][color=blue][color=green][color=darkred]
>> >>santosh wrote:[/color][/color][/color]
[color=blue][color=green][color=darkred]
>> >>>> I am wondering why a call to fork fails to print some statements
>> >>>> in the child.[/color][/color][/color]
[color=blue]
> What are the newsgroups where
> fork calls are on topic?[/color]

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

re: fork call

On 2006-05-24 14:54:17 +0200, pete <pfiland@mindspring.com> said:

[color=blue][color=green]
>> 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.[/color]
>
> What are the newsgroups where
> fork calls are on topic?[/color]

Unix-related ones.

--
Sensei <senseiwa@mac.com>

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

re: fork call

In article <44749454$0$14792$4fafbaef@reader4.news.tin.it>,
Sensei <senseiwa@mac.com> wrote:[color=blue]
>On 2006-05-24 14:54:17 +0200, pete <pfiland@mindspring.com> said:[/color]
[color=blue][color=green]
>> What are the newsgroups where
>> fork calls are on topic?[/color][/color]
[color=blue]
>Unix-related ones.[/color]

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.

re: fork call

Joe Smith wrote:[color=blue]
> "pete" <pfiland@mindspring.com> wrote[color=green][color=darkred]
>> >>santosh wrote:[/color][/color]
> [snip]
>[color=green][color=darkred]
>>>>>>> I am wondering why a call to fork fails to print some
>>>>>>> statements in the child.[/color][/color]
>[color=green]
>> What are the newsgroups where fork calls are on topic?[/color]
>
> 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[/color]

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/>

re: fork call

Joe Smith wrote:[color=blue]
>
> "pete" <pfiland@mindspring.com> wrote
> [snip][color=green][color=darkred]
> >> >>santosh wrote:[/color][/color]
>[color=green][color=darkred]
> >> >>>> I am wondering why a call to
> >> >>>> fork fails to print some statements
> >> >>>> in the child.[/color][/color]
>[color=green]
> > What are the newsgroups where
> > fork calls are on topic?[/color]
>
> Forks, pipes, segments. These are, for me,[/color]
? three very similar things. The[color=blue]
> fork is on the left hand side of the plate.
> The pipes run overhead. BTW, I
> liked the link you posted for pipes recently:-)[/color]

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

--
pete

re: fork call

"pete" <pfiland@mindspring.com> wrote in message
news:4474F6B7.2418@mindspring.com...[color=blue]
> Joe Smith wrote:[color=green]
>>
>> "pete" <pfiland@mindspring.com> wrote
>> [snip][color=darkred]
>> >> >>santosh wrote:[/color]
>>[color=darkred]
>> >> >>>> I am wondering why a call to
>> >> >>>> fork fails to print some statements
>> >> >>>> in the child.[/color]
>>[color=darkred]
>> > What are the newsgroups where
>> > fork calls are on topic?[/color]
>>
>> Forks, pipes, segments. These are, for me,[/color]
> ? three very similar things. The[color=green]
>> fork is on the left hand side of the plate.
>> The pipes run overhead. BTW, I
>> liked the link you posted for pipes recently:-)[/color]
>
> I used to cut threads on pipes in a machine shop.[/color]

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